auto-start extension

[bn-darindouglass-zz]

During some internal discussions about state management, my team weighed the benefits of a simple delay-based state solution vs using mount.lite to manage state.

One argument for the delay-based approach was everything was started automatically on first use which generally simplifies work in the repl during development.

After some thought, we found a middle-ground that we figured may be nice to include in the upstream library as a new extension: mount.extensions.autostart.

This extension provides a new defstate which wraps the main mount.lite.State with a new record that will auto-start on first deref. The start fn it'll use is configurable (we use mount.extensions.explicit-deps/start, but it defaults to standard mount.lite/start).

Here's our code.

Any thoughts? We wanted to gauge interest before submitting a PR against the upstream library.

[bn-darindouglass-zz]

Drafted #28

[aroemers]

Hi Darin,

Thank you for your elaborate message and the PR. It's interesting that you want said "delay-based" or "lazy" functionality, because if you have a look at the 3.x branch, there you'll see a feature called *lazy-mode* that can be turned on. I believe this does exactly what you are after. It does not have the locking from your PR yet, so I will need to add that.

However, 3.x is not released yet. While working on it, I wanted to see how I could reimagine mount-lite by solely relying on this delay-like behaviour. This became the redelay library (and it has the locking 😉 )

So, as I see it, there are several ways you forward here:

1. You find that redelay library fits your requirements. It does not have something like explicit-deps though, but then again, do you need it in a completely lazy setup?
2. You find that the original mount is OK too, as it has a lazy start feature called "cljc mode". But you probably chose mount-lite over mount for a reason.
3. I merge the extension you provided, because it looks good to me. And since you implemented it as an extension, it won't affect other users at all 👍
4. I have to release 3.x. However, I'm rather busy right now, so I'm not sure if and when that will happen.

Let me know where you stand on this. I'll review your PR anyway.

[bn-darindouglass-zz]

Interesting, thanks for getting back to me.

1) We'll give redelay a look. We use explicit deps primarily for the only-start-what-i-care-about functionality as well as for the documentation it provides. It's not a game-breaker in any way but definitely a nice to have. 2) Yeah we swapped to mount.lite because of explicit deps. We have some state that's poorly handled/implemented with mount and ran into problems several times where mount/starting our system started things that we didn't actually care about which caused confusion and failing tests.

From the look of things redelay is fills the exact use-case we're looking for. Thanks for the heads up on that.

As for my PR, given 3.x is "if and when" instead of "when" it may make sense to get it through so the behavior is available for those who use mount.lite instead of redelay.

[aroemers]

Closed by #28.