This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-10
Channels
- # ai (2)
- # beginners (3)
- # boot (113)
- # bristol-clojurians (2)
- # cider (77)
- # clara (43)
- # cljs-dev (48)
- # cljsrn (9)
- # clojure (319)
- # clojure-austin (2)
- # clojure-czech (4)
- # clojure-denmark (4)
- # clojure-france (4)
- # clojure-italy (4)
- # clojure-russia (2)
- # clojure-serbia (10)
- # clojure-spec (79)
- # clojure-uk (64)
- # clojurescript (109)
- # clr (3)
- # conf-proposals (21)
- # core-async (19)
- # cursive (26)
- # datascript (11)
- # datomic (19)
- # devcards (1)
- # emacs (25)
- # figwheel (9)
- # hoplon (31)
- # jobs (7)
- # jobs-discuss (14)
- # leiningen (10)
- # lumo (11)
- # off-topic (37)
- # om (40)
- # onyx (4)
- # perun (8)
- # planck (3)
- # rdf (4)
- # re-frame (40)
- # ring (11)
- # ring-swagger (2)
- # rum (21)
- # spacemacs (2)
- # specter (50)
- # untangled (93)
- # yada (13)
@sova I’m testing if can get the benefits (as far as I understand them) of om.next in rum. So I’m now looking at the querying part of om.next. It seems I can copy the query parser and some other namespaces. I have to reimplement the indexer, i think, as it is highly coupled to om.next. I cannot promise that I will ever finish it, so please don’t hold your breath. It always helps though if there are people with om.next experience that also know how rum works
@sova I was just pointed to https://github.com/roman01la/scrum it is almost what i want i believe
I was just about to comment about global state, but getting rid of it is mentioned in the roadmap
Not sure I really like the subscribe/dispatch model. I guess it can have better performance due to how react works?
What do you see as a downside of the subscribe/dispatch model? As for the subscribe part, isn’t this how everything works in the async world?
Aren't UIs pretty synchronous when you think about it? Server requests are async, but you don't need an event model for those if you don't want to, you can use callbacks too.
I'd also like to explicitly give my components their parameters, and not have them depend on outside state
Yes I agree. I was maybe generalising too much. I didn’t know about Carry, thanks for the link.
https://github.com/tatut/tuck this is another good one. Doesn't have much docs though
and what's unique is that the components can have their own state atoms, which means it's easier to start using in the middle of a project
I do think having one state IS better, but if you already have thousands of lines of code, it's hard to move to that model 🙂
Hi! I'm playing around with alumbra (a Clojure GraphQL library) and having a lot of fun. Has someone used rum with GraphQL or built any mixins for use with GraphQL?
The only frontend graphql tool I know of is https://github.com/retro/graphql-builder