Fork me on GitHub
#funcool
<
2017-01-04
>
martinklepsch05:01:53

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

martinklepsch07:01:43

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

martinklepsch07:01:28

(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)

niwinz08:01:08

I'm not clearly understand that

niwinz08:01:08

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

martinklepsch08:01:59

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

niwinz08:01:33

why not just define a var and access to it?

niwinz08:01:25

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

niwinz08:01:41

that is fully accesible on all events

niwinz08:01:58

and in fact is its purpose

niwinz08:01:31

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

niwinz08:01:52

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

martinklepsch08:01:13

yeah, that seems easy enough

martinklepsch08:01:21

I guess I jumped at component to quickly 🙂

niwinz08:01:52

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

martinklepsch08:01:41

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

martinklepsch08:01:05

forces you to make the dependencies explicit

niwinz08:01:35

yeah, but that is the price of that?

niwinz08:01:54

I mean, every decision has it's own tradeoffs

niwinz08:01:09

some decisions has X advantadges and Y disadvantages

martinklepsch08:01:22

@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?

niwinz08:01:25

really component X is more than Y?

niwinz08:01:31

@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"

martinklepsch08:01:21

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)

niwinz08:01:50

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

niwinz08:01:34

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

martinklepsch08:01:11

Hm, not a fan of mount 🙂

martinklepsch08:01:45

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.

martinklepsch08:01:18

Can you remember what conflicts you had with component?

niwinz08:01:54

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.

martinklepsch08:01:37

yeah makes sense 👍

martinklepsch08:01:52

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

mccraigmccraig10:01:42

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

mccraigmccraig10:01:40

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

martinklepsch10:01:53

@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?

martinklepsch10:01:58

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

mccraigmccraig10:01:13

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

mccraigmccraig10:01:45

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

martinklepsch17:01:48

@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

martinklepsch17:01:44

Maybe I’ll try adapting your component function for now