Has anybody here used <HTTPS://GitHub.com/quile/component-cljs> in combination with re-frame? If so, how did it work out for you?

I've got a subjective architecture question about interceptors. Right now I've got an event handler that takes some input, which it then destructures and parses in order to use it. I'm adding a :before interceptor that is parsing out the input in order to do something else and pass some additional context to the event handler. Which of the following options make more sense to you? 1) Each part just does the minimal thing - so the interceptor pulls out the input and uses it, but doesn't pass the input along. The event handler then pulls the input out and adds it to the DB. 2) The interceptor adds the parsed input to the context going into the event handler. The event handler doesn't have to worry about parsing the input at all, but copies the information from the context to the app-db. 3) The interceptor adds the parsed input directly to the app-db, and the event handler uses it from there. Happy to post example code if this doesn't make sense without it.

3 does not seem/look like a "flow" of data. So 1 or 2 seem better from what you described

@danielpquinn I can't comment on component, but perhaps this (semi) alternative might be useful https://github.com/Day8/re-frame-async-flow-fx/blob/develop/README.md @shaun-mahood I'd have your Interceptor inject its computations into :coeffects ... after all, it is an input required by the event handler?

Has anyone used Devcards with re-frame? Any hiccups? (No, I'm not going for the pun)

@mikethompson: Yes, the input is required by the event handler. That's the way I've been leaning, so I'm glad I'm not too out to lunch 🙂

@ivanreese I found this on google, might help: https://github.com/bhauman/devcards/issues/105

Good find! Thanks. Looks like this is an area of active exploration.