2 min readAug 1, 2019
Sure. I haven’t really invented a new paradigm but I recognize that it has been a little less popular as of late.
- Animations — You don’t need Components for animations you need HTML Elements. The general approach is similar to something like React Hooks. On entering a certain state you can apply your animation and use disposal methods, in this case
onCleanup
to remove them on disposal. The context is the effect rather than the Component. Effects still get set up and torn down. You correctly identifiedwillRemove
as a tricky area. Most libraries are synchronous here anyway so even with awillRemove
lifecycle function the library will go on without you if your process takes time. In other words, having a Component under a ternary and switching the condition tofalse
is never going to give you a smooth fade out. Even if you trigger the animation the Component will be removed and the replacement inserted. So other mechanisms are introduced. React Transition Groups(https://github.com/reactjs/react-transition-group) come to mind. I haven’t done a ton of research in this area, but I’ve found that generic solutions tend to be inconsistent, buggy, and complex. Enough so to get in the way of 3rd parties trying to expand the library core. It is an interesting area, and I’m interested to see what sort of progress can be made. This did come up as a question on our github, there was a discussion and I’ve provided some examples: https://github.com/ryansolid/solid/issues/39 - Data Lifecycle — While Solid doesn’t have lifecycles a series of repeatedly executed lifecycles, as you construct down the tree it creates contexts through each binding. It starts with a root (that I hide behind the render function which all returns a disposer method to free the whole mount point) and then each effect and JSX binding belongs to its parent context. This goes on nested and so on. Whenever effect re-evaluates it cleanups all children, and re-creates dependencies on the new evaluation. The key part is because it’s fine grained(and with some clever memoization techniques used in lists) it can mostly defer re-evaluation to the leaves meaning that generally you aren’t re-evaluating higher level stuff often. But this means when you do, like switching a panel/page, everything automatically disposed, the old content/state/registered
onCleanups
etc.. So load your data however you want on initial execution(AJAX, stores, etc) and apply it to your local state. If necessary register someonCleanup
hooks for any explicit subscriptions you make and you should be good to go.
I hope that mostly answers your questions. Let me know if you have anymore. And I’m usually free to chat about this on our gitter: https://gitter.im/solidjs-community/community