matrix 2024-02-16

Gonna spend today writing up the new "async" Cells developed for Flutter/MX, because Flutter is massively async and the existing MX approach involving two cells per async transaction would get old fast. tl;dr: The two cell approach had a formulaic Cell decide, based on other reactive state, to generate sth async, such as an XHR. The response callback function, provided when dispatching the XHR, mset! a second input cell created just to absorb the response reactively. The new async cells roll all that up into one cell. The f/mx internals, when processing the value computed by a cell flagged as :async? true, know to take the value computed (which must be a Future) and apply a .then that cleverly mset! the same cell to the response, triggering reactive dataflow to anyone watching the cell. Importantly, after applying the .then, the MX internals had the cell take on the interim value nil. This means any formulaic cell interested in the async cell had to be coded to handle nil gracefully. An obvious enhancement here would be to support values other than nil as the interim value. One nicety: we can specify :async-then, an optional function to massage a response when received before the clever mset! . The internals did get interesting, and quite a refactoring was required, but you do not tell me your problems! 🤣

👍 1
👏 3
🙌 2

I for one am glad the default as nil has been kept! :D I made very heavy use of this feature of MX when I was creating a Bluetooth heavy app. Thanks again, @hiskennyness, for making MX, and making it work with CLJD!

nil is marvelous! It shall remain the default! 🙂