Hacker News new | ask | show | jobs
by shoover 3795 days ago
Interesting times for experimental Swift UI libraries coming out, with tcp-json-swift [1] mentioned last week and now this.

This is an excellent synthesis and transfer of related technology. Nice work! Some of the Swift- and NS-isms are tricky to follow without knowing Mac dev, and I'm still wrapping my head around how it all wires together, but especially the update loop is very clear and small and I think a unique use of Rx to blend into React/virtual-dom/Elm ideas.

My perspective is I am trying to bring the Elm Architecture to F# but started out porting virtual-dom.js on the bottom. It's early and ugly and just at the point of having to deal with patching children nodes, so parts of this are quite relevant. One avenue I intend to check out is performing set operations on a flat node list and using something like protocol methods on parent views to add and remove children, so that part of the code is definitely going to trigger some thoughts.

The dictionary of observables indexed by node threw me at first. AFAICT the virtual views, action types, and updates all compose, and then once it's time to do anything with real views (the patch operation in diff/patch terms) just that part is handled independently per node? (EDIT: Ah, I see the context dispatch is composed as in Elm, and only pushing down model updates is separate.) It's dead easy compared to the work virtual-dom.js has to do to index patches, index DOM nodes, and walk the DOM applying updates. This seems to handle all that with much less code, with a couple caveats:

1) The ability to reorder children is missing, right?

2) Any plan to support laziness to curb rerendering sections of the virtual tree? It's probably not needed for many apps, but for some reason the feature gets air time in discussions around React and Elm. (Looks like all observables get called unconditionally once per update, too?)

[1] - https://github.com/chriseidhof/tcp-json-swift

1 comments

Thanks for the feedback! To answer your questions: 1) Currently, yes, though that is something that will definitely be implemented as we work on this further 2) Laziness there is something that we're going to look into. We need to first assess how much of an impact it has on performance - if that's big enough to warrant taking further (which it likely will be for more complex apps) then we need to figure out the best way to perform a deeper diff of the model Good luck with the F# port - I'd be very interested to hear more!
Great, I will keep an eye on your repo and look forward to seeing how you solve those problems, if it comes to it.

There's not much to say on the F# front yet except that the goal is to get a taste of functional rendering from an app state atom for Windows GUIs and F# and the Elm Architecture seem like the most approachable way to get there for me. So far the work consists of porting the node, thunk, and widget designs from virtual-dom.js to F# types and functions and using .NET reflection to create and patch live views. Work continues on the patch function, but seeing your code is definitely creating an itch to move on to the architecture.