Skip to content

Releases: mobxjs/mobx-state-tree

v7.0.0-pre.2

01 Aug 17:56
fc60d76
Compare
Choose a tag to compare
v7.0.0-pre.2 Pre-release
Pre-release

Breaking Changes

  • Validate state tree instances instead of snapshots in the SnapshotProcessor.is override by @airhorns in #2182
  • Fix typings for snapshot processor by @thegedge in #2198 (we also consider this a fix)

Features

  • Type create/validate to accept an instance type by @thegedge in #2199

Fixes

  • Fix tsconfig and typechecking by @thegedge in #2200
  • Fix typings for snapshot processor by @thegedge in #2198 (for some users, this may break types if you relied on prior type assumptions)

Migration Path

For most users, migrating from v6 -> v7 will be straightforward and require no work. However, we have made a breaking change in the assumption for types.snapshoProcessor and its is method.

In v6, we validated processed snapshots in this method. But now we will only validate instances. If you upgrade to v7 and all of your TypeScript types and runtime tests are passing, no additional work necessary on your end.

If this change has broken you, it may in fact be surfacing subtle bugs or gaps in your type modeling where your codebase is considering two different types to be "the same" because they have matching SnapshotOut shapes. If you need to preserve that behavior in your codebase, you might consider writing custom logic to check for this type of equality. MST is specifically taking a stance to check against Instances and valid SnapshotIn types.

The snapshot processor typings have also changed, which may break during upgrade, but for the most part we have relaxed them to be more correct. If you relied on old workarounds, you may be able to remove custom type assertions.

Full Changelog: v6.0.1...v7.0.0-pre.2

v7.0.0-pre.1

12 Jul 02:01
0ef2ba2
Compare
Choose a tag to compare
v7.0.0-pre.1 Pre-release
Pre-release

Breaking Changes

  • Validate state tree instances instead of snapshots in the SnapshotProcessor.is override by @airhorns in #2182

Migration Path

For most users, migrating from v6 -> v7 will be straightforward and require no work. However, we have made a breaking change in the assumption for types.snapshoProcessor and its is method.

In v6, we validated processed snapshots in this method. But now we will only validate instances. If you upgrade to v7 and all of your TypeScript types and runtime tests are passing, no additional work necessary on your end.

If this change has broken you, it may in fact be surfacing subtle bugs or gaps in your type modeling where your codebase is considering two different types to be "the same" because they have matching SnapshotOut shapes. If you need to preserve that behavior in your codebase, you might consider writing custom logic to check for this type of equality. MST is specifically taking a stance to check against Instances and valid SnapshotIn types.

Full Changelog: v6.0.1...v7.0.0-pre.1

v6.0.1

07 Jul 19:20
9c199a5
Compare
Choose a tag to compare

Breaking Changes

  • No breaking changes

Features

  • No new features

Fixes

  • Improve typing for model type substitutability. by @thegedge in #2189
  • Improve typing for isXYZType narrowing functions by @thegedge in #2190

Docs

Full Changelog: v6.0.0...v6.0.1

v6.0.0

06 May 19:16
745f283
Compare
Choose a tag to compare

Breaking Changes

Features

  • Added a new feature, hasEnv, to support #2163

Fixes

  • Union types will now be fixed, but this also may break TypeScript for some users
  • Array operations produce condensed patches when we can, but this may break for some users who relied on the patch generation as it was
  • fix: do not mutate properties object by model constructor by @dangreen in #2176
  • Fix/get members 2173 by @evinosheaforward in #2174
  • fix: #2138 linter issues with fail function by @JuanJo4 in #2171

Tests

Docs

Community/Developer Changes

New Contributors

Full Changelog: v5.4.2...v6.0.0

Migration Guide from v5 to v6

TypeScript update

Make sure you're using TypeScript 5.3.3, and you have the following compiler flags:

{
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true
}

Or the shorthand:

{
  "strict": true,
  "noImplicitReturns": true
}

Removing $nonEmptyObject

We removed the $nonEmptyObject key from the ModelCreationType. For the most part, this was an internal feature that would only have shown up in TypeScript errors. There is no runtime change, but if you have any custom typings that relied on something like [$nonEmptyObject] - you should be able to eliminate those.

Union Type Changes

In the past, named enumerations had more specific type than unnamed enumerations. You may have some TypeScript errors where you were using anonymous enumerations. You can type those with the union of literal values inside the enumeration now.

import { t } from "mobx-state-tree";

/**
 * In MobX-State-Tree 5.4.1, this is typed as:
 * ISimpleType<"Red" | "Orange" | "Green">
 */
const namedEnum = t.enumeration("Color", ["Red", "Orange", "Green"]);

/**
 * In MobX-State-Tree 5.4.1, this is typed as:
 * ISimpleType<string>
 */
const anonymousEnum = t.enumeration(["Red", "Orange", "Green"]);

/**
 * If you use mobx-state-tree@^6.0.0, both of these will be typed as:
 * ISimpleType<"Red" | "Orange" | "Green">
 */

This has also fixed #1525 and #1664

For #1525, If you had models with properties that were unions including other models, you may have done some type assertions to resolve the issue. This should no longer be necessary. In most cases, we don't expect this to show up as errors. But the inferred types have changed. Look through your codebase for unions of models in the properties of other models, and if you hit any issues, you may be able to use better typing form here on out.

The issue presented itself in #1664 when using types with different creation and instance types which were passed to unions inside of arrays. If you see more TypeScript errors aside from the other items mentioned, look for types.union that creates a union which includes Array, Map, or Model types. If you had any custom type assertions, you may no longer need those.

Array operation patch changes

When an Array type calls clear, or splices itself from index 0, the generated patch is different. We have shortened the operations to be a patch like:

op: "replace", path: "", value: []

If you use onPatch and expect any specific shape of patches from Array.clear or Array.splice, you may need to update your app logic to handle the changed patch generation.

getEnv now throws

If you call getEnv and there is no environment, it will now throw an error. Previously, it would return an empty object.

Check your codebase for getEnv calls, and guard against this error with hasEnv, which will return true if the current state tree has an environment, or false if not.

v6.0.0-pre.3

17 Apr 14:49
Compare
Choose a tag to compare
v6.0.0-pre.3 Pre-release
Pre-release

Breaking Changes

Features

  • We added a new feature, hasEnv, to support #2163

Fixes

  • Union types will now be fixed, but this also may break TypeScript for some users
  • Array operations produce condensed patches when we can, but this may break for some users who relied on the patch generation as it was
  • Fix: do not mutate properties object by model constructor: by @dangreen in #2176
  • Fix getMembers duplicating actions into views by @evinosheaforward in #2174

Tests

Docs

Community/Developer changes

Full Changelog: v5.4.1...v6.0.0-pre.3

v5.4.2

17 Apr 14:32
Compare
Choose a tag to compare

Version 5.4.2 fixes a few regressions, and comes with documentation updates. Thanks to everyone who contributed!

Breaking Changes

No breaking changes

Features

No new features

Fixes

  • Fix: do not mutate properties object by model constructor: #2176
  • Fix getMembers duplicating actions into views #2174

Tests

No new tests

Docs

  • Docs: add comparison between React Context/Reducer: #2158
  • Docs: fix broken link: #2165
  • Docs: add recipe for mst-form-type: #2168

New Contributors

Full Changelog: v5.4.1...v5.4.2

v6.0.0-pre.2

10 Mar 19:59
Compare
Choose a tag to compare
v6.0.0-pre.2 Pre-release
Pre-release

Breaking Changes

Features

  • We added a new feature, hasEnv, to support #2163

Fixes

  • Union types will now be fixed, but this also may break TypeScript for some users
  • Array operations produce condensed patches when we can, but this may break for some users who relied on the patch generation as it was

Tests

No new test-only contributions

Docs

Community/Developer changes

What's Changed

New Contributors

Full Changelog: v5.4.1...v6.0.0-pre.2

v5.4.2-pre.1

01 Mar 15:38
d08be68
Compare
Choose a tag to compare
v5.4.2-pre.1 Pre-release
Pre-release

Version 5.4.2-pre.1 is an important build for everyone to test out, because it includes some TypeScript changes that could be seen as either bug fixes or breaking changes.

RFC - should we consider these changes bug fixes (bump to 5.4.2) or breaking changes (bump to 6.0.0)

import { t } from "mobx-state-tree";

/**
 * In MobX-State-Tree 5.4.1, this is typed as:
 * ISimpleType<"Red" | "Orange" | "Green">
 */
const namedEnum = t.enumeration("Color", ["Red", "Orange", "Green"]);

/**
 * In MobX-State-Tree 5.4.1, this is typed as:
 * ISimpleType<string>
 */
const anonymousEnum = t.enumeration(["Red", "Orange", "Green"]);

/**
 * If you use mobx-state-tree@5.4.2-pre.1, both of these will be typed as:
 * ISimpleType<"Red" | "Orange" | "Green">
 */

CodeSandbox for version 5.4.1

CodeSandbox for version 5.4.2-pre.1

It's reasonable to call this change a "bug fix", but for projects that relied on the prior behavior, a patch version might "break" their TypeScript types, if they've typed around our existing bug.

The change comes from #2151, which also "fixes" #1525 and #1664 again, by changing types.

We have also removed NonEmptyObject. If a project had relied on that for any kind of type casting, I think that could also be seen as a breaking change.

And of course, we've moved to TypeScript 5.3.3, which shouldn't have a direct impact downstream, but we have previously only called out TS 3.0 or later. This is not strictly a breaking change, and it's technically in line with "TypeScript 3.0 or later", but it could be seen as disruptive to move so far ahead in TypeScript without ample warning in our version.

Breaking Changes

  • Improved typing for union types by @thegedge in #2151 (maybe, see introduction)
  • Eliminate NonEmptyObject by @thegedge in #2152 (maybe, see introduction)
  • Bump typescript from 3.9.10 to 5.3.3 by @thegedge in #2146

Features

  • No new features

Fixes

  • Some might consider #2146, #2151, and #2152 to be bug fixes, rather than breaking changes.

Tests

  • No test-only additions.

Docs

Community/Developer changes

New Contributors

Full Changelog: v5.4.1...v5.4.2-pre.1

v5.4.1

06 Feb 01:47
4dba8ec
Compare
Choose a tag to compare

Version 5.4.1 fixes a small import bug, and updates tests and documentation. Thanks to everyone who contributed!

Breaking Changes

No breaking changes

Features

No new features

Fixes

Tests

Docs

New Contributors

Full Changelog: v5.4.0...v5.4.1

v5.4.0

27 Nov 22:01
Compare
Choose a tag to compare

Version 5.4.0 brings performance improvements and improved developer experience around importing types as t, and passing nodes to postProcess snapshot operations.

Breaking Changes

  • No breaking changes

Features

Fixes

Tests

Docs

New Contributors

Full Changelog: v5.3.0...v5.4.0