This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-13
Channels
- # beginners (78)
- # boot (27)
- # cider (13)
- # cljs-dev (41)
- # cljsrn (4)
- # clojure (216)
- # clojure-android (1)
- # clojure-conj (6)
- # clojure-greece (1)
- # clojure-italy (11)
- # clojure-russia (127)
- # clojure-spec (63)
- # clojure-uk (34)
- # clojurescript (68)
- # core-async (5)
- # cursive (5)
- # data-science (1)
- # datomic (4)
- # dirac (11)
- # editors (7)
- # events (1)
- # graphql (12)
- # hoplon (39)
- # jobs (1)
- # liberator (3)
- # lumo (101)
- # off-topic (14)
- # om (3)
- # onyx (3)
- # parinfer (14)
- # re-frame (10)
- # reagent (2)
- # remote-jobs (1)
- # ring-swagger (17)
- # sql (21)
- # untangled (38)
- # vim (3)
- # yada (23)
@tony.kay: An easier read for first timers than previous documentation because there are no longer gaps. I really like it. If you needed to shorten it the om/computed
in depth explanation could be put elsewhere - for getting started all application programmers need to know is that functions passed down to child components are to be handled differently: you can get a long way without knowing exactly why that's the case. That's my proofreading feedback.
Thanks for proofing it! I think the new additions also make it seem more approachable. No parsers needed anywhere, until you start wanting to convert queries to graph walks of SQL
What is great about it is the flow - telling a story and filling missing bits in as go.
Yeah, I had tried to do that in the quick tour in the dev guide, but I think it was too light
The first time users needs to go away having understood all, or almost all. The computed stuff is difficult and not absolutely required.
Thing is I’ve just spent several pages telling that you “just pass stuff as props”. I’ll re-read it and see if I can make it shorter without feeling like I’m going to lose people
I've never really 'got' what's going on with computed, so perhaps it is hard for others too. All I know is as an app programmer I follow the rule - "if its not props I use computed".
But the line is important - between what user of framework needs to know and what builder of the framework needs to know.
agreed. Understanding computed is one I think the user should know..even though I see your point that there is a rule to follow. Cause if you don’t follow the rule, it looks like it works…until it doesn’t
and a lot of devs will run with things that look like they work, then get bogged down when they do “weird things”
and there’s nothing I dislike more that banging my head against a wall when trying to get something done. I guess that’s why I want to knw why…helps me debug
Perhaps I’ll move the why to a section marked optional, and simplify the main flow to just state the rule…“if you want to make stuff up that didn’t come from the query engine and pass it to a child, put it in computed”
I reworded this:
The problem is that Om can optimize away a re-render
of a parent when it can figure out how to pull just the data of the child on a refresh, and in that case the
callback will get lost because only the database data will get supplied to the child!
I have an ident that points to a ident that I use in a form that then breaks on untangled.ui.forms/validate-form
Are idents that point to idents supported in om.next or am I breaking stuff? Or maybe I found a issue on form-support in untangled