Calling `(reset)` at the cljs-repl causes the system to be completely dropped

[cjsauer]

When calling (reset) at the cljs-repl, I noticed that my system was acting very strangely. Within a component, data that I had assoc'd into my component map was being completely lost, resulting in null errors. For example, closing a core.async channel in the stop lifecycle method was throwing "no implementation of close! for nil".

I believe I've pinpointed the source of the error, and it's really simple. This line here: https://github.com/plexus/chestnut/blob/master/src/leiningen/new/chestnut/src/cljs/chestnut/system.cljs#L26

When calling (reset), I believe that instead of calling (go) after stopping, it should just call (start). That's really what (reset) is intended to mean in my opinion: stop the system, and then start it again. (go) seems to only be a one-time setup call, but I may be mistaken.

[featheredtoast]

I build reset like that as to ensure that an entirely new system gets started with new component definitions on code reload - otherwise after a code reload, the "old" components are still referenced, even when "new" component definitions may exist.

If you're looking for data/connections to persist across restarts, the only way to do it currently is through defonce outside of the system, as cljs' reset does not implement something like a suspendable interface to persist component attributes. It isn't the cleanest, but it allows for the system to work well with figwheel's reloading.

In your core.async channel example, are you associating a new channel in your component map on start? If so, it should be associated in your component (in the new system) on the stop call, regardless of whether the system was started through go or start. Mind showing an example case?

[featheredtoast]

I'm gonna close this out until this use case gets cleared up, feel free to re-open when you come up with an example