I've worked with a model much like this, and as an experience report: it resulted in a lot of pain. Atoms inside atoms, or really more than one atom for the entire state of your app results in to many sources of mutability. On top of that, you have the problem of async updates: some part of your state may or may not exist depending if some async call to the server has completed yet. I can't say much more without seeing your code, but I would use this as an opprotunity to re-think the design of the app a bit.
If you are getting nils in unexpected places you can either nil-prune (what you're asking for here), or you can ask "why am I getting a nil here when I didn't expect it...how can I keep from doing this in the future?". Perhaps the answer is as simple as never calling the render function of a component until all its state exists (Om.Next takes an approach somewhat like this). On Sat, Sep 10, 2016 at 11:12 AM, Deon Moolman <[email protected]> wrote: > Hi Sean, > > Good point - as you have noticed, my use case is in ClojureScript - I'm > using reagent cursors (hence the deref) fairly heavily to chop my main atom > up and send only the relevant bits to components, but still allow them to > locally modify their state. > > In my specific case, I do lookups for parts of the tree that may not > exist, and in that case 'nil' is the obvious return value. > > Cheers, > - Deon > > On Fri, Sep 9, 2016 at 6:55 PM, Sean Corfield <[email protected]> wrote: > >> Like Stuart, I don’t encounter atom-or-nil as a common pattern – could >> you explain why you have functions that might return an atom or might >> return nil? >> >> >> >> FYI, We have about 40,000 lines of Clojure at World Singles and just a >> handful of atoms (and most of those are going away as we refactor the code >> to use Component more extensively). >> >> >> >> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> >> "If you're not annoying somebody, you're not really alive." >> -- Margaret Atwood >> >> >> >> On 9/9/16, 1:10 AM, "Deon Moolman" <[email protected] on behalf >> of [email protected]> wrote: >> >> >> >> Hey all, >> >> >> >> I'm having some pain with atoms and dereferencing nil - mostly around my >> functions sometimes returning an atom and other times nil - I don't really >> want to create a special 'nil' atom and do the bits for returning that and >> I don't want to be checking nils absolutely everywhere when nil-punning >> works perfectly otherwise, so I was wondering what the pitfalls of this >> approach would be? >> >> >> >> (extend-type nil IDeref >> >> (-deref [_] nil)) >> >> >> >> Effectively, make @nil nil-pun to nil. makes sense to me? >> >> >> >> Cheers, >> >> - Deon >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to [email protected] >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/clojure/ot_sD2sJW0A/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to [email protected] > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
