Lessons learned / Things I would have done differently

[vlaaad]

There are couple of higher level design decisions that I feel are somewhat limiting, so if I were to make cljfx-next (I'm not), I would do these differently:

1. I would extend Lifecycle protocol to keywords and functions instead of relying on :fx.opt/type->lifecycle. This thing actually might be fixable in cljfx, but ensuring no breaking changes will be very difficult.
2. I would not use renderer middleware at all (see Can renderer middleware be replaced with extension lifecycles? #13), and instead rely more on extension lifecycles.
3. I would use namespaced keywords (instead of plain ones) for props, and would try to allow extension lifecycles be parts of component description they wrap:

;; so that this:

{:fx/type fx/ext-on-instance-lifecycle
 :on-created prn
 :desc {:fx/type :label
        :text "text"}}

;; would become something like this:

{:fx/type :label
 fx/ext-on-instance-created prn
 :fx.labeled/text "text"}

4. renderer abstraction would become "view description that has access to data" instead of "transformation from data to view description"
5. I would explore making lifecycles or their surroundings a transducer context. It would be nice to write (comp (dedupe) (fx/advance-lifecycle)) to skip same descriptions, and it might prove itself useful on other areas.
6. I would explore how to make it truly reactive instead of doing what react does, so when change happens, a system would know what exactly should be updated instead of doing "virtual dom diffing". See svelte.

Some problems I found that don't map well to cljfx/react model:

• some props don't belong on any particular component: managing the focus between different components is "somewhere else".
• inequality of prop values does not always mean reassignment of new value has to happen: event listeners are invoked when events happen, so they need to know their value only at a later point in time. Having the same event listener while the prop is set and looking up the latest value while the event is fired is more efficient.

[not-in-stock]

Please take a look at this versioning semantics, it might be an almost gentle way to introduce breaking changes https://github.com/noprompt/meander#versioning-semantics

[vlaaad]

I have a feeling that mutators are just a different kind of lifecycle. Also, something like "memoize-latest-call" would greatly simplify all lifecycles.