@curlyfry but isn't the reframe flow only usable with reagent components? I want to use the re-com tour, and wan't to call custom functions on different steps.

@danielgrosse Are you saying that re-com components are not Reagent components? Because they are 🙂 https://github.com/Day8/re-com/blob/master/README.md#mvc (sorry if I misunderstood you)

I know this. But I want to use the subscription within a normal function. Currently the tour from re-com initializes into a list of atoms for each step which get set to true, if the step is active. But there is currently no possibility to execute other functions, while clicking through the tour. So I thought to watch the atom for changes and call functions on change.

So, re-com reset! the atom on next step and you want to watch this and react somehow?

f.e. dispatch event with the some logic @danielgrosse so track is the good decision i think

FYI https://github.com/Day8/re-frame/issues/284

@andre correctly. But re-com isn't connected to re-frame. It uses a local atom and hasn't the possibility to dispatch events.

if your app is using the re-frame you can add re-com map into app-db in the event handler which creates the tour, and then subscribe on this map

or if not you can just use track is good decision too

but, yes you need track anyway, to add it into app-db you need to track re-com map too

it depends on your app structure

@danielgrosse we made both re-com and re-frame and I can guarantee that they work together

Those callbacks in re-com just do a dispatch

re-frame subscriptions can act as the inputs to the components. All works pretty well

(But I haven're read all the above, so perhaps I'm missing a concern)

@mikethompson I use re-com together with re-frame and it works really great. But while trying the tour of re-com I got to this wall. So if I add the tour map to the reframe db, I could watch it and react on the changes. Seems logical.

Some note to re-com. It would be great, if the used strings could be in a i18n format.

Oh, I see, yes, the tour component. We have never ended up using it. So I'm a bit blind to it

Happy to take a PR if you have opinions about what should be better explained

It is working good, for the simple case it's provides. If I find the time, I will try to contribute to it.

I don't manage to us the subscriptions outside of a reagent component. How is this possible? e.g.

(defn foo [] 
(let [sub (subscription [:updates])]
(do some stuff with sub))

(foo)
(dispatch [:update])

Has anyone built a coffect for token authentication yet? If not, it's on my short term list of things to work on so I'll put it up on the docs when done.

@shaun-mahood Hi, I'm doing a demo project which use twitter oauth2 but have not finished yet. Maybe 1 to 3 weeks.

@cmal: Cool, that would be a nice thing to have an example on when you finish!

Question about coding style: if I have an event that updates something in app-db and also changes the app's current panel, is it better to use reg-event-db and add (assoc :active-panel :main) to the threading macro, or use reg-event-fx and add :dispatch [:activate-panel :main]? I think I prefer the latter approach but doing this sort of thing makes my app use reg-event-fx ~30% of the time instead of 10% as the README says.

@paulb: Not sure what everyone else does, but if I have an event that only changes app-db then I tend to keep it together. You could also use dispatch-n if you want to keep the changes separate. I wouldn't worry about what % of the time you are using reg-event-fx - I'm starting to move to using it everywhere even if I'm only changing :db, since reg-event-db is really only syntactic sugar on top of it now.

thanks, good point, maybe I will only use dispatch if it's a behavior that I might want to change or extend later, and otherwise keep it together

@paulb: Even if you want to change it later, it's pretty easy to refactor when that comes up - my recommendation would be to keep it as simple as possible until you need to change it.

yeah probably so. do you use the path interceptor much? By doing all the app-db updates in one threading macro instead of doing dispatches, it makes it harder to use that interceptor because you're making a lot more "global" changes to app-db instead of delegating it to a dispatch. I'm not sure how useful that interceptor is though.

@paulb: I never use path, but I build small enough apps that I don't need to. Some of the devs on large re-frame apps use it all the time though, so I expect it becomes a lot more useful as your app-db gets more complex. I can see it making a lot of sense to use dispatch-n - once to update the data, once to update the panel. I try to never dispatch from inside an event.

@paulb @shaun-mahood +1 for that, I use the path interceptor at work (large db) but not for my small hobby project (trivially small/flat db)

Say, is it possible to have one coeffect depend on another one? I have one coeffect that parses and stores per-environment configuration and another one which accesses LocalStorage, and I want to use a LocalStorage key that comes out of the config coeffect.

I can see how to break it up into two event handlers, just curious if there’s another way to do it

@andre a couple of questions: (1) is there a way to have re-frisk expand a sub-tree completely? I was looking for shift+click or opt+click or something to do this. (2) I realise you can use add-data add-data-in but would it be possible to have bookmarks that you could access from the browser itself? (possibly using localStorage to remember them across sessions)?

Hrmm... i guess i have a problem with my [Object object] keys here for the add-data option

since they are records wrapping a GUID