Fork me on GitHub
#re-frame
<
2017-10-10
>
lovuikeng03:10:33

@mikethompson in your full-stack FAQ, as well as comment from @danielcompton #clojure "The architectural pattern for "re-frame on the server" is CQRS" , how does re-frame work with CQRS, and why is CQRS a better fit as re-frame backend besides the event-based nature?

danielcompton03:10:01

What we’re saying is that taking the idea of “What would re-frame look like on the server?” It comes out looking like CQRS

danielcompton03:10:44

CQRS is a broad architectural pattern, not any one implementation

lovuikeng03:10:44

agree, @danielcompton although the pattern has been around for long, notable implementation is yet to be evolved

lovuikeng03:10:57

of course, again, the event-based nature of both seems like a good fit

jeaye03:10:53

Just came across it the other day and it sounds like a great idea; basically, offload as much of the re-frame event handling as possible to a background thread.

danielcompton03:10:24

but more for web stuff

danielcompton03:10:35

seems like a good idea to run it in a background thread though

danielcompton03:10:40

especially for RN

jeaye03:10:23

Yep, agreed.

jeaye03:10:59

I'll have to dig deeper then, after this trace work has stabilized.

cmal08:10:21

Hi, how can i track the state history in re-frame, just like what the redux-state-history https://www.npmjs.com/package/redux-state-history do?

cmal08:10:09

Thank you!

Bravi17:10:32

is it better to have a few subscriptions, each returning a single value or having 1 and returning a map of few values?

manutter5117:10:46

Depends if they're going to change individually or as a group

manutter5117:10:10

So for example, if you've got a subscription for "current album" that's got name, artist, tracks, etc., and you switch back and forth between different albums, the information will all change at the same time, so a single subscription returning a map would be fine.

manutter5117:10:50

Or if you're doing a "Plan Your Menu" screen, showing current entree, current appetizer, current beverage, and current dessert, and the user can mix and match as they please, then separate subscriptions for each would work best.

Bravi17:10:00

in my case, I basically need to show a game score, game speed, time left and whether the game has ended or not

Bravi17:10:08

so basically 4 - 5 different things

jeaye17:10:14

I'd separate them.

Bravi17:10:35

yeah, that’s how I did it and now it makes sense why I’d want to do it

Bravi17:10:49

and therefore I’d have each separate component, right?

Bravi17:10:59

that would update only that single part

Bravi17:10:11

I mean, each subscription would update one single component

Bravi17:10:24

in my case

manutter5117:10:35

I think that would be easier to maintain and refactor. You can always wrap them in a parent component if you need to keep them together.

lovuikeng17:10:22

yes, @bravilogy sounds like best to put them in a score-panel component in separate labels, and clue it to main-panel

lovuikeng17:10:39

something like header panel is good

binora08:10:41

@U7DKLTCQJ there's also https://github.com/gadfly361/soda-ash which did most of the work for me . great work @U0522BZ1R

lovuikeng09:10:52

yes, @U5CHXVC64 I tend to enjoy more with syntax of @U0Z325BSR though 🙂

kennethkalmer09:10:58

Thanks everyone! I might need to revisit the smooth client side routing post again, it was my very early days in Clojure

lovuikeng18:10:35

@danielcompton can't wait for your The REPL to resume subscription, enjoy your paternity leave 😃

jeaye18:10:33

Woah, that opensourcery (kenneth) guy looks way too much like me.