mvu_layer 0.3.7
mvu_layer: ^0.3.7 copied to clipboard
An Elm-inspired state management for leveraging benefits from the Elm architecture while still being Dart friendly.
0.3.7 #
- Added a new boolean field
disposesProcessorto MVU widgets and providers. This flag controls whether the associatedMVUProcessorshould be automatically disposed when the widget is removed from the widget tree. - For widgets that receive an external processor (e.g., via
MVUBuilder.ofProcessororMVUProvider.fromProcessor), the default isfalseto avoid disposing shared or reused processors. - For widgets that create their own processor by encapsulating their
initandupdatefunctions, the default istrue, meaning the processor will be disposed when the widget is removed from the tree. - Fixed a resource leak where active subscriptions were not disposed if the widget was removed from the widget tree. Previously, if a widget was removed, its subscriptions could remain active because their disposers were not called. This only happened when the widget was removed, not when the model changed and the subscription was no longer returned. With the new
disposesProcessorfield, setting it totrueensures that all subscriptions and resources are properly cleaned up when the widget is disposed. - Added a new
MVUProcessor.disposemethod to allow manual disposal of the processor and its resources. This is useful for scenarios where you want to clean up resources without relying on the widget lifecycle. - Breaking change: The
disposemethod onMVUWidgetand similar widgets has updated to have theirMVUProcessoras an argument. This way you can access the processor and call itsdisposemethod if needed or call thedispatchwith new messages to disable active subscriptions or reflect the disposal in the possibly shared model. This should be used with care, for most cases we recommend using the subscription system to handle long-running tasks or external events, as it provides a cleaner and more controlled way to manage resources.
0.3.6 #
- Breaking change: The method
useModelfromMVUProcessorwas renamed touseModelSync. NowuseModelis a new method that returns aFutureusing the model. This method leverages the MVU loop to guarantee that the model is up to date when the future completes. TheuseModelSyncmethod is still available for synchronous access to the model, but it's not recommended to use it on flows that dispatches messages that might update the model.
0.3.5 #
- Add support for an
onDisposefunction on theMVUBuilderconstructor anddisposefunctions on theMVUWidgetand similar widgets. These will be called when the widget is removed from the widget tree. - Add a helper function on
CmdandDispatchmaking it possible to consume aCmdwith anotherDispatchfunction. This might be useful for test scenarios, enabling peeking into the messages dispatched.
0.3.4 #
- Expose the
modelEqualityfunction on theMVUProcessorconstructor. This can be used to avoid multiple renders when the model has no changes that affect the view. This is useful for performance and to avoid some bugs when using theMVUProcessoron the background.
0.3.3 #
- Bugfix: Processor was being lazily initialized, which was causing some issues like subscriptions not starting when using it from outside the view. Now it's initialized on the constructor.
0.3.2 #
- Expose the
MVUProcessorto allow the processing of messages from outside the view. This is useful for testing and for processing messages on the background. Also can be used to add subclasses of theMVUProcessorinto dependency injection solutions to pass the same processor instance across different locations on the app. - Add functions
useModelandsubscribeinto theMVUProcessorso you can access the model and subscribe to it from outside the view. This is useful for testing and for implementing CLI apps. You can import only thepackage:mvu_layer/mvu_processor.dartto avoid thedart:uiimport. - Add widgets
MVUProviderandMVUContext. This is used to get theMVUProcessorthrough the widget tree, adding a view to theMVUProcessoronly when needed. - Add subscriptions like Elmish. These subscriptions are enabled on the background and can be used to dispatch messages to the update function. The subscriptions have an id and are recalculated on every model change. If a new id is returned, the subscription starts and if an old id is not returned, the subscription is cancelled. This is useful for implementing long running tasks like timers or listening on external events.
0.3.1 #
- Add widget classes
MVUWidgetandMVUWidgetWithTickerto 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.dartinstead ofpackage:mvu_layer/mvu_layer.dart - If both are imported in the same file, the
Cmdhelper 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
Cmdhelpers 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 anonDisposefunction instead.
0.2.3 #
- Accept
doRebuildon mostCmdhelpers so it's possible to skip the rendering between some commands
0.2.2 #
- New helper
ofModelActionto use the latest model as argument of the action
0.2.1 #
- Fixes the
MsgProviderTreeby 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
MsgConnectorcode
0.1.12 #
- Support continuations on
doWithModel
0.1.11 #
- Extra
MsgBuilderwithTickerProvidersupport
0.1.10 #
- Helpers for command only continuations
0.1.9 #
- Helpers for command only dispatching
0.1.8 #
- New name constructor
modelinitialize theMessengerwith simple model
0.1.7 #
- New helper
ofModelFuncto use the latest model as argument of the function
0.1.6 #
- New helper
doWithModelto create actions using the latest model
0.1.5 #
- Support
onInitfunction for using theBuildContextwhen initialising
0.1.4 #
- Only call
setStatewhenmounted
0.1.3 #
- Downgrade
asyncto 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.