mvu_layer 0.3.1 mvu_layer: ^0.3.1 copied to clipboard
An Elm-inspired state management for leveraging benefits from the Elm architecture while still being Dart friendly.
0.3.1 #
- Add widget classes [MVUWidget] and [MVUWidgetWithTicker] to simplify the implementation of MVU widgets that might need single init dependencies. These dependencies should be final fields and can be accessed from the init and update function without polluting the model or requiring a closure.
0.3.0 #
- Almost a complete reimplementation of the elmish structure, but still dartish.
- If you want to use the new API, you can import
package:mvu_layer/mvu.dart
instead ofpackage:mvu_layer/mvu_layer.dart
- If both are imported in the same file, the
Cmd
helper will clash. This is by design so we don't accidentally mix both. The new API is not backwards compatible and is fundamentally different. - The new API is heavily dependent on the new Dart 3 features, like records and sealed classes. It's not possible to use it on Dart 2.
- The new API is not yet stable and might change in the future depending on the feedback.
- The new API documentation is not yet very helpful, but the example project is a good starting point.
- The Elmish book is a good reference for the new API, even if it's written for F#.
- The recent subscription API is not yet implemented in the new API, but it's planned.
- The new API is more restrictive and will not allow you to do some things that were possible before. This is by design, as dispatching any kind of model transition in any place was breaking the flow and reasoning of complex apps. The new API has an explicit update function that is the only place where you can change the model. This is similar to the Elm architecture, but it's not as restrictive as it's possible to use the
Cmd
helpers to dispatch actions from the update function. - On the new API, use the new dispatch function on the view to dispatch messages to the update function. You can't set the model directly anymore from it. When testing you can still use the init function to set the initial model required for the test.
- The new API is more verbose, but it's also more explicit and easier to reason about. It's also more type safe and will help you to avoid some common mistakes. Remember to model your messages as sealed classes to get the full experience and the compiler help.
- The old API will only receive bug fixes and will not receive any new features. It's recommended to migrate to the new API if possible. The old API will be deprecated in the future.
- The new API is not yet fully tested and might have some bugs. Please report any issues you find.
0.3.0-dev.1 #
- Experimental real MVU using features from Dart 3.
0.2.4 #
- Fix broken disposer of
MsgProvider
. Offers anonDispose
function instead.
0.2.3 #
- Accept
doRebuild
on mostCmd
helpers so it's possible to skip the rendering between some commands
0.2.2 #
- New helper
ofModelAction
to use the latest model as argument of the action
0.2.1 #
- Fixes the
MsgProviderTree
by not requiring a child onMsgProvider
0.2.1-connector-preview #
- Type the messenger on provider
- Change the connector to a stateless widget
0.2.0 #
- Null safety soundness
0.1.13 #
- Simplify
MsgConnector
code
0.1.12 #
- Support continuations on
doWithModel
0.1.11 #
- Extra
MsgBuilder
withTickerProvider
support
0.1.10 #
- Helpers for command only continuations
0.1.9 #
- Helpers for command only dispatching
0.1.8 #
- New name constructor
model
initialize theMessenger
with simple model
0.1.7 #
- New helper
ofModelFunc
to use the latest model as argument of the function
0.1.6 #
- New helper
doWithModel
to create actions using the latest model
0.1.5 #
- Support
onInit
function for using theBuildContext
when initialising
0.1.4 #
- Only call
setState
whenmounted
0.1.3 #
- Downgrade
async
to better compatibility
0.1.2 #
- Use sync dispatching for preventing race conditions or dead-locks
0.1.1 #
- Follow dartfmt conventions and better package description.
0.1.0 #
- Initial release
- Small but probably sufficient API surface.