Conversation
This is just experimentation and should not be taken seriously.
The Column even has an implementation of mutation. Not wired up to window root (and no app logic, no actions).
The app logic is a function from actions to a mutation. WIP checkpoint - this adds some of the types but does not yet build the element tree from the app logic or deliver events.
Actually wire up mutations and an event flow so counting clicks works, though of course it's still super rough in a variety of ways.
This is the start of an Elm-like pattern for building apps. There's now a trait for the vdom (which is the correct direction; an enum is not powerful enough), and support in the api for map functionality.
The "rusty" app architecture continues the exploration started with elm but with important differences. The view tree is responsible for dispatching events, rather than that being done in a big hash map (maintained in the reconciliation process). Unlike elm, event callbacks get mutable access to the app state. Also moving in the direction of static types rather than downcasting, but this is being done in stages. WIP
The `Column` still uses erased types, but the underlying View type now has an associated type for its state, and also takes the previous view.
We can use the view in MemoizeState, which is simpler and more efficient than running the callback to generate a new view.
This implements the `View` trait for boxed views; possibly we want to newtype this, as it requires a bunch of explicit derefs. Also fixes a bug in memoize where it wasn't updating the view in the memoize state.
Add ChildMutation datatype which optimizes as it's built, and avoids allocation in the skip case. Change the signature of the reconcile method to return a MutationFragment rather than push an element onto a vec. This is a cleaner return type and also optimizes the skip case.
There might be a more elegant way to do this, but for now putting the event body into Rc<RefCell> makes it work.
The "thunk" is now a concrete type rather than dyn Fn, which has a bunch of advantages: it can infer types better, and it doesn't need the interior mutability.
Contributor
Author
|
I am closing this pull request as I do not anticipate further development of this branch. Going forward I anticipate more exploration in the idiopath branch, also called "Xilem." |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is just a branch I'm using for experimenting with a layered architecture, code named "lasagna." At the moment it doesn't do anything, but has some basic types in place for tree mutation, app logic, etc. The goal is simply for me to learn whether the architectural ideas are viable.