Clojurians Log v2

Yeah I understand what WatchEvent is used for and I think it’s great (I use it for some more complex operations) but it complicates some things I tried to implement as well

I think I’ll need to drop Potok again despite the initial fun: 1. I’d like to use component and that quickly causes circular dependencies with the store-view 2. I’d like to make-available additional stuff when processing events without introducing globals

(The cyclic dependency appears only because I tried to “inject” the db into the store so I can pass it to event handlers and similar)

I'm not clearly understand that

at least it does not make sense (the cyclic dependency...), seems like more ortanization problem that potok's problem

I needed access to (fb/->FirebaseStub) (`:db`) in some event handlers (see point 2) and thought I could parameterize the store (a forked version of it) in a way that would allow me passing additional things to event handlers

why not just define a var and access to it?

an other option, just put the firebase db as a key in the state

that is fully accesible on all events

and in fact is its purpose

later, if you want materialize that state to an "atom" but without db reference, just filter keys that you don't want see on the materialized atom, it is pretty easy to do with rx

(->> store (rx/map #(dissoc % :db)) (rx/to-atom))` (or something similar)

yeah, that seems easy enough

I guess I jumped at component to quickly 🙂

Personally, I don't see any advantage of using component on front

yeah maybe. I like the organization and separation it enforces though

forces you to make the dependencies explicit

yeah, but that is the price of that?

I mean, every decision has it's own tradeoffs

some decisions has X advantadges and Y disadvantages

@niwinz one thing with the state in watch events btw: The WatchEvent flow is async and the state is static it could become outdated and result in weird results, right?

really component X is more than Y?

@martinklepsch yes and no, if you perform an async op and then you want to acess to state, just emit an other event that does something as a "continuation of flow"

I don’t know I don’t see a huge price for using component except that it doesn’t work well with some things (which can make it unbearable to use some times)

for me this is already high price, designing everything to component and in future found myself, spendig time fighting with, when some new feature that I want to introduce conflicts a little bit with component

I think mount is a good middle solution, on the other hand I'm not using it right now on frontend

Hm, not a fan of mount 🙂

I think “designing everything around component” might have some cost but also makes the boundaries of these components more clear. Which in my experience also makes them often easier to use.

Can you remember what conflicts you had with component?

No conflicts, just the effort of adapt everything to component, and maybe little conflicts like that one that you have had. It is not a hard opinion, is just a pragmatic decsions.

yeah makes sense 👍

I think I’ll try what you suggested, thanks for the pointer 🙂

i didn't like component, but i do like being able to compactly specify systems of objects - i built something with cats to do it - https://github.com/employeerepublic/deferst

(though i haven't made it work on cljs yet)

@mccraigmccraig I’ve been meaning to understand what cats is good for for quite some time 😄 would you mind outlining how it helped with that library?

The code isn’t immediately understandable to me, which is a good reason for me to shy away from using something ...

cats does all the plumbing - i just plugged together a couple of standard monads and coerce everything to type and cats does the rest

i did have to re-invigorate a couple of concepts which got retired from cats though 😬

each object gets built and added to the state with https://github.com/employeerepublic/deferst/blob/master/src/deferst/system.cljc#L110 while https://github.com/employeerepublic/deferst/blob/master/src/deferst/system.cljc#L139 composes all the build operations ... everything else is peripheral

@niwinz I ended up writing a Rum mixin that starts/stops systems and provides it to components via context, pretty happy with that solution I think. Now I want to make a defc variant that passes (partial emit! store) as first argument

😄

Maybe I’ll try adapting your component function for now