Declaratively subscribe method proposal...

[michaeldanielbell]

What do you think about having a subscribe method that accepts a callback. Maybe even a parameter to specify what it should listen to. Could be a nice way to declaratively use in re:dom.

i.e

const listener = store.subscribe('a.b', (callback) => {
     console.log(`Magic callback data: ${callback}`)
})

//if needed
listener.unsubscribe();

What do you think?

[pakastin]

The problem with subscribes is, that if you forget to unsubscribe or there's a bug skipping unsubscribe, you'll get memory leaks really easily..

[michaeldanielbell]

Fair enough.
Just out of interest, do you use re:dom store in some kind of declarative way.
i.e By way of updating the store and then having those changes populate through your app?

[pakastin]

I usually have a separate client-side API, which I use to change the app state. Then I'll do a single update for the whole app in a requestAnimationFrame throttle so that there's only one update per animation frame.

In addition to that, there might be some separate temporary component state, but I try to avoid that.

[pakastin]

I should create an example app with RE:DOM to show how I personally use RE:DOM 😎

[pakastin]

Currently I don't actually even use redom-store, I tend to just:

state = {
  ...state,
  changedProperty: changedValue
}

😄

[michaeldanielbell]

How are you passing that state data to your various components?

[pakastin]

With view.update(state)

[pakastin]

and list.update(items), and router.update(route, state), and place(visible, state) 😎

[michaeldanielbell]

Yes, make sense.
But I guess I mean, since your passing state around to various parts of your app. It seems like a bit of a manual process, to update all your views, that use the same state.

Thats what I was thinking with some kind of redux like subscribe
So component data stays in sync with state

[michaeldanielbell]

Perhaps an example of how you use state with re:dom would be good :)

[pakastin]

agreed 😅