@martinklepsch can you log that request in the issues? Otherwise I'm afraid I can forget about it

Sure

Done

Pretty cool I think 😛

Makes global state a bit more “controllable” 🙂

Nice work, one think that I'm pretty surprised is how you use rum for start the system. In my mental mode, I will done the same process but in reverse order. The system will start the ui (not the ui that starts the system)

@niwinz using it with Potok like this btw:

(rum/defc system-wrap < (sys/system (new-system store))
                        {:will-mount (fn [s]
                                       (js/console.log "Injecting system" (::sys/system s))
                                       (ptk/emit! (:store (::sys/system s)) (->System (::sys/system s)))
                                       s)}
  [root-comp]
  (root-comp))

It makes me feel strange that the UI part of the app is responsible to start the rest of the stuff.

Hm, interesting thought, never considered turning the UI into a component. I think since everything is “exported” via component context it might not be possible but not sure

In my mental mode, UI is just a part of the system that should be started from the main entry point, and it has its dependencies

starting UI and on mount start the rest of the system looks very strange on my mental model

In fact, on my apps I perform many things before the app's UI starts

Well the system is started before the UI is mounted

i.e. Nothing is rendered before the system has started

I mean that the UI layer and the system is pretty coupled...

In my approach, I will have functions that starts the system and UI is jut a part of it

Also, when I run tests, I just run them in nodejs,without headless browser

so I don't want import anythig related to UI on tests

so the approach of having UI just a component makes very easy just don't include it when on tests builds

again, is just share my opinion 😄

> so the approach of having UI just a component makes very easy just don't include it when on tests builds Or you just start the system and don’t have the UI at all

I don’t see a big difference in that regard but in theory I’d say you are right. UI depends on other stuff in the system and could be treated as component

hmm not true, you will need the system-wrap component mounted

in order to run the same code that initializes the potok stream

@niwinz I can just do (component/start (new-system store))

on the other hand you will have to repeat the same logic of initialization on tests and ui

(js/console.log "Injecting system" (::sys/system s))
                                       (ptk/emit! (:store (::sys/system s)) (->System (::sys/system s)))

the system injection is done on the component...

Ah, you mean that, I see

I see, it just two lines of code

Yeah, that would have to be done manually. Not a huge deal though I’d say

But as I said, I agree. UI could be a component like others that depends on parts of the system

it's not huge deal, but I prefer just having to no repeat initialization logic, just because it can change in future and you should not forget to change it on other locations

I actually do the same, start my whole app from the root App component and do a bunch of initialization on will-mount etc

Works pretty well and I remount on every figwheel load so I get a clean state

@rauh clean slate as in all data wiped out? If you repeat initialization logic on updates you probably construct some state outside that logic?

@martinklepsch I guess I didn't mean that. I do a whole remount but my state lives in two places: Datascript + component local state. Both persist the reloads.

So I actually get the same state, or else I have a bug in my SPA and need to remember some local state.

@niwinz toyed briefly with the "UI is a component” idea, definitely seems possible but it’s probably where I’ll stop and call it pragatism 😄

On my apps I'm not using component nor mount, but I first start router, the potok stream and other stuff, and then the UI. I understand that your approach also works well, it just looks strange to me.

I don't like much that my entry point is going to be coupled to UI

@martinklepsch Have you or anyone else you know tried using javelin with rum? Is that even possible? I like hoplon/javelin — but not ideal if wanting to do native mobile - and leverage react-native. How are you storing data for rum apps?

@donmullen in an atom and then I use derivatives https://github.com/martinklepsch/derivatives

Have never used Javelin so I can’t really compare

(there are plenty of alternatives to derivatives)

👍:skin-tone-2: