This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-10
Channels
- # aleph (4)
- # beginners (32)
- # cider (12)
- # cljs-dev (56)
- # cljsrn (7)
- # clojars (3)
- # clojure (165)
- # clojure-dev (33)
- # clojure-germany (1)
- # clojure-italy (27)
- # clojure-russia (7)
- # clojure-spec (24)
- # clojure-uk (62)
- # clojurescript (37)
- # core-async (7)
- # core-matrix (1)
- # cursive (9)
- # data-science (8)
- # datomic (8)
- # duct (4)
- # events (1)
- # figwheel (7)
- # flambo (3)
- # fulcro (43)
- # hoplon (25)
- # jobs-discuss (8)
- # lein-figwheel (4)
- # luminus (2)
- # off-topic (35)
- # om (8)
- # om-next (3)
- # onyx (30)
- # pedestal (62)
- # portkey (2)
- # protorepl (2)
- # re-frame (40)
- # reagent (9)
- # shadow-cljs (123)
- # specter (30)
- # sql (22)
- # testing (1)
- # uncomplicate (40)
- # unrepl (3)
- # vim (13)
- # yada (5)
@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?
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
CQRS is a broad architectural pattern, not any one implementation
agree, @danielcompton although the pattern has been around for long, notable implementation is yet to be evolved
Any of you guys use https://github.com/seantempesta/cljsrn-re-frame-workers ?
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.
New to me, there's also https://github.com/yetanalytics/re-thread
but more for web stuff
seems like a good idea to run it in a background thread though
especially for RN
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?
is it better to have a few subscriptions, each returning a single value or having 1 and returning a map of few values?
Depends if they're going to change individually or as a group
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.
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.
in my case, I basically need to show a game score, game speed, time left and whether the game has ended or not
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.
yes, @bravilogy sounds like best to put them in a score-panel component in separate labels, and clue it to main-panel
later can be fancy with semantic-ui of statistic component https://react.semantic-ui.com/views/statistic with tips from https://www.opensourcery.co.za/2017/02/12/using-semantic-ui-react-with-re-frame/
This is very cool too https://www.opensourcery.co.za/2016/05/27/smooth-client-side-routing-in-a-figwheel-only-project/
@U7DKLTCQJ there's also https://github.com/gadfly361/soda-ash which did most of the work for me . great work @U0522BZ1R
yes, @U5CHXVC64 I tend to enjoy more with syntax of @U0Z325BSR though 🙂
Thanks everyone! I might need to revisit the smooth client side routing post again, it was my very early days in Clojure
@danielcompton can't wait for your The REPL to resume subscription, enjoy your paternity leave 😃