Yes, a shared channel looks nice :-) https://github.com/amiron/tryouts/blob/master/src/cljs/tryouts/notifications.cljs#L11-L25
On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote: > > On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron > <adrian....@gmail.com<javascript:> > > wrote: > >> >> >> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote: >>> >>> >>> If you don't pass app state data to this component then you don't need >>> to bother with build at all. If you need a component that doesn't need app >>> state but does need component local state you need to use om.core/graft. >>> Refer to the documentation on om.core/graft and look at the examples in the >>> repo. >>> >>> Channels could work. However :shared was also designed with this >>> scenario in mind, you could use an atom with the message in it and placed >>> it in :shared if the message is not an important piece of state for the >>> rest of your application. There are also examples of :shared in the repo as >>> well. >>> >>> HTH, >>> David >>> >> >> Thank you for your reply. I've used graft and it works fine with >> channels. I will also try :shared, but I guess I will have to call refresh! >> after I swap the shared atom? >> > > No the simplest thing would be to call om.core/root again, however if this > is not really a global change (i.e. switching logged in user) then you have > to pay for re-rendering your entire UI and throwing away all component > local state. > > Sounds like the simplest solution for you is a :shared message channel. > Components that care about the message need to set up go loops and update > their state when they receive a new message. > > HTH, > David > On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote: > > On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron > <adrian....@gmail.com<javascript:> > > wrote: > >> >> >> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote: >>> >>> >>> If you don't pass app state data to this component then you don't need >>> to bother with build at all. If you need a component that doesn't need app >>> state but does need component local state you need to use om.core/graft. >>> Refer to the documentation on om.core/graft and look at the examples in the >>> repo. >>> >>> Channels could work. However :shared was also designed with this >>> scenario in mind, you could use an atom with the message in it and placed >>> it in :shared if the message is not an important piece of state for the >>> rest of your application. There are also examples of :shared in the repo as >>> well. >>> >>> HTH, >>> David >>> >> >> Thank you for your reply. I've used graft and it works fine with >> channels. I will also try :shared, but I guess I will have to call refresh! >> after I swap the shared atom? >> > > No the simplest thing would be to call om.core/root again, however if this > is not really a global change (i.e. switching logged in user) then you have > to pay for re-rendering your entire UI and throwing away all component > local state. > > Sounds like the simplest solution for you is a :shared message channel. > Components that care about the message need to set up go loops and update > their state when they receive a new message. > > HTH, > David > On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote: > > On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron > <adrian....@gmail.com<javascript:> > > wrote: > >> >> >> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote: >>> >>> >>> If you don't pass app state data to this component then you don't need >>> to bother with build at all. If you need a component that doesn't need app >>> state but does need component local state you need to use om.core/graft. >>> Refer to the documentation on om.core/graft and look at the examples in the >>> repo. >>> >>> Channels could work. However :shared was also designed with this >>> scenario in mind, you could use an atom with the message in it and placed >>> it in :shared if the message is not an important piece of state for the >>> rest of your application. There are also examples of :shared in the repo as >>> well. >>> >>> HTH, >>> David >>> >> >> Thank you for your reply. I've used graft and it works fine with >> channels. I will also try :shared, but I guess I will have to call refresh! >> after I swap the shared atom? >> > > No the simplest thing would be to call om.core/root again, however if this > is not really a global change (i.e. switching logged in user) then you have > to pay for re-rendering your entire UI and throwing away all component > local state. > > Sounds like the simplest solution for you is a :shared message channel. > Components that care about the message need to set up go loops and update > their state when they receive a new message. > > HTH, > David > On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote: > > On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron > <adrian....@gmail.com<javascript:> > > wrote: > >> >> >> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote: >>> >>> >>> If you don't pass app state data to this component then you don't need >>> to bother with build at all. If you need a component that doesn't need app >>> state but does need component local state you need to use om.core/graft. >>> Refer to the documentation on om.core/graft and look at the examples in the >>> repo. >>> >>> Channels could work. However :shared was also designed with this >>> scenario in mind, you could use an atom with the message in it and placed >>> it in :shared if the message is not an important piece of state for the >>> rest of your application. There are also examples of :shared in the repo as >>> well. >>> >>> HTH, >>> David >>> >> >> Thank you for your reply. I've used graft and it works fine with >> channels. I will also try :shared, but I guess I will have to call refresh! >> after I swap the shared atom? >> > > No the simplest thing would be to call om.core/root again, however if this > is not really a global change (i.e. switching logged in user) then you have > to pay for re-rendering your entire UI and throwing away all component > local state. > > Sounds like the simplest solution for you is a :shared message channel. > Components that care about the message need to set up go loops and update > their state when they receive a new message. > > HTH, > David > On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote: > > On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron > <adrian....@gmail.com<javascript:> > > wrote: > >> >> >> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote: >>> >>> >>> If you don't pass app state data to this component then you don't need >>> to bother with build at all. If you need a component that doesn't need app >>> state but does need component local state you need to use om.core/graft. >>> Refer to the documentation on om.core/graft and look at the examples in the >>> repo. >>> >>> Channels could work. However :shared was also designed with this >>> scenario in mind, you could use an atom with the message in it and placed >>> it in :shared if the message is not an important piece of state for the >>> rest of your application. There are also examples of :shared in the repo as >>> well. >>> >>> HTH, >>> David >>> >> >> Thank you for your reply. I've used graft and it works fine with >> channels. I will also try :shared, but I guess I will have to call refresh! >> after I swap the shared atom? >> > > No the simplest thing would be to call om.core/root again, however if this > is not really a global change (i.e. switching logged in user) then you have > to pay for re-rendering your entire UI and throwing away all component > local state. > > Sounds like the simplest solution for you is a :shared message channel. > Components that care about the message need to set up go loops and update > their state when they receive a new message. > > HTH, > David > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com 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 clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.