Re: [ClojureScript] Reagent/re-frame drag event weirdness
On Wednesday, July 22, 2015 at 1:31:16 PM UTC-7, David Pidcock wrote: > Thank you. > So expected behaviour :D > > Quick clarifying question : when you say "Events use the flyweight pattern" > do you mean Javascript events themselves, or the Clojurescript event objects > that wrap them? NVM = I answered my own question with some experimentation :D Javascript events can be passed into a setTimeout function call just fine. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Reagent/re-frame drag event weirdness
Thank you. So expected behaviour :D Quick clarifying question : when you say "Events use the flyweight pattern" do you mean Javascript events themselves, or the Clojurescript event objects that wrap them? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Reagent/re-frame drag event weirdness
I'm playing with Reagent + re-frame (and re-com) for a toy project of mine and
I noticed something strange.
I'm creating a component I want to use to drag things around with:
(defn drag-handle
[]
(fn []
[re-com/label :style {:padding "5px"} :label "||"
:attr {:id (:id combatant)
:draggable true
:on-drag-start #(re-frame/dispatch [:drag-start %])
:on-drag (fn [event]
(prn (.clientX event))
(re-frame/dispatch [:drag event]))
}]))
The handler looks like this :
(re-frame/register-handler
:drag
(fn [db [_ event]]
(prn "after dispatch ; " (.-clientX event))
When I use dispatch asynchronously (.-clientX event) is correct when printed
from the function attached to the component, but nil when it reaches the
handler.
if I use dispatch-sync, the output is consistent.
Is this a bug in re-frame/dispatch router-loop code , or core/async? Or
expected behaviour?
I haven't tried this with a vanilla (chan), and I've only tested in Chrome
Could it be that the javascript object isn't "realized" until it has been read,
and the mouse event is "dead" after the router-loop executes the (http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Architecture Question / Handling app-state transactions outside of the component hierarchy?
At first I read DB and Transient state and was "huh?". Then I skimmed over the linked article. Nice. So if I were to hazard an analogy, its like data script is a root Om atom with querys in the place of cursors, right? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Om: saving scroll position
On Monday, March 24, 2014 3:52:32 PM UTC-7, Scott Nelson wrote: > I need the scroll state to persist beyond a single lifecycle of the list > component which is why a purely local treatment is not sufficient (to my > knowledge). The scroll position could be tracked locally (either in a > buffered channel like you mention or directly in the local state) but would > ultimately need to be stored somewhere outside of the component (perhaps on > IWillUnmount). > > I think the only way to avoid a re-render is to store the scroll state in a > separate, global atom. I think I'd rather deal with the re-renders and > perform some debouncing to keep them minimal. Hmm - that might work. Use the sliding channel of size 1 to keep only the latest scroll event, and then only read from that in WillUnMount, pushing it into app-state at that time. Then read from app-state in DidMount. That will probably cause an extra render, but hopefully only one. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Om: saving scroll position
On Monday, March 24, 2014 9:58:53 AM UTC-7, Scott Nelson wrote: > Thanks David. I'll keep my eye on that issue. > > Debouncing sounds like a good idea for reducing the number of renders. I'm > solving a similar issue in another part of the app by debouncing the channel > containing the updates: > https://github.com/scttnlsn/jot/blob/master/src/jot/ui.cljs#L141 > > Perhaps this isn't even worth worrying about until there's a noticeable > performance problem. Is this why you're on the fence about some sort of > "silent" update? Caveat : I still have no idea what I'm talking about WRT Om/React. That said : Why listen to all scroll events and update your app-state with them every time? Is there no way to preserve this information in component local state? Would a sliding buffered channel help? Perhaps you could ditch the WillMount listener and just get the last value put on the channel in DidMount? I have no idea if that will work, but it seems you're only consuming the latest scrollTop value in DidMount... -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM: Interesting mismatch between app-state and passed-in data
You got me thinking : if we're storing drop-index, why not just use it during
the build phase as follows :
(apply dom/ul #js {:className "sortable" :ref "sortable"}
(flatten (map-indexed
(fn [idx item]
[(when (= idx (:drop-index state))
(sortable-spacer (second
(:cell-dimensions state
(om/build line-item item {:opts opts
:key :id} )
])
init-list ))
Which gives us the spacer item in the right place without "adulterating" the
list with it. Not sure if flatten here will perform any better than the
insert-at function, but I'm not quite sure if there's a better way to achieve
this sort of thing.
On Friday, February 7, 2014 4:37:24 PM UTC-8, David Pidcock wrote:
> Hmm, really? How would you do it differently?
> Seems like the perseus orderer uses the same technique (slicing out the card
> you're about to drag, and inserting a placeholder at that index instead)
>
> On Friday, February 7, 2014 10:25:41 AM UTC-8, David Nolen wrote:
> > Without a minimal case it's hard for me to understand what the problem is.
> > I will say the spacer technique in my sorting example was a simple hack and
> > not the way I would do a sortable - I suspect it may be the source of some
> > of these issues.
> >
> >
> >
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM: Interesting mismatch between app-state and passed-in data
Hmm, really? How would you do it differently? Seems like the perseus orderer uses the same technique (slicing out the card you're about to drag, and inserting a placeholder at that index instead) On Friday, February 7, 2014 10:25:41 AM UTC-8, David Nolen wrote: > Without a minimal case it's hard for me to understand what the problem is. I > will say the spacer technique in my sorting example was a simple hack and not > the way I would do a sortable - I suspect it may be the source of some of > these issues. > > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM: Interesting mismatch between app-state and passed-in data
I have been thinking about this a little bit. Perhaps the interesting thing to me is not that the item-map might have changed some value within it between render and click, it's actually that the line item component is referring to a different item entirely, than the one it rendered. So even though React has the correct data-reactid based on the key I gave it, and all the rendered information in the display refers to, say, Item #3, the onClick handler is referring to a different item in the list (an adjacent one), as if there's been two render phases - one that built the component from the values, and a second phase that attached the handlers to the dom node. This seems like a subtler problem than "The atom changed between render and click". The approach of pulling out values in the head of the component function seems to work, but I'm wondering if I should instead, always simply refer to items by id, rather than passing around the item "object". -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM: Interesting mismatch between app-state and passed-in data
Well that didn't work :D
I actually got that the wrong way around.
Looks like the best way to pass the correct value is to use destructuring to
get access to the value at the time the function is invoked and pass that value
along to any handlers, not the atom/cursor (or use something like (into {} ..
) to get a snapshot.
On Thursday, February 6, 2014 7:36:21 PM UTC-8, David Pidcock wrote:
> Yes, I am still getting my head around this -- that the rendering of the item
> can be out of sync with the atom it was handed is still a little wonky to me.
> :)
>
> I'm wondering if it isn't better to simply avoid the destructuring and pull
> out the data with (:key @atom) everywhere. I will experiment with that some
> to see if that makes it more accurately reflect actual state.
>
> On Thursday, February 6, 2014 5:23:38 PM UTC-8, David Nolen wrote:
> > Cases like this are to be expected and may need to be explicitly handled.
> > Dereferencing data will always give you something current which may not be
> > what the handler closure was given.
> >
> >
> > David
> >
> >
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM: Interesting mismatch between app-state and passed-in data
Yes, I am still getting my head around this -- that the rendering of the item can be out of sync with the atom it was handed is still a little wonky to me. :) I'm wondering if it isn't better to simply avoid the destructuring and pull out the data with (:key @atom) everywhere. I will experiment with that some to see if that makes it more accurately reflect actual state. On Thursday, February 6, 2014 5:23:38 PM UTC-8, David Nolen wrote: > Cases like this are to be expected and may need to be explicitly handled. > Dereferencing data will always give you something current which may not be > what the handler closure was given. > > > David > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] OM: Interesting mismatch between app-state and passed-in data
There appears to be some strange timing issue in my application.
I am using a variation on the sortable example, but instead of using internal
state to represent the order of the items, I am using a sort-by function over
the app-state.
I suspect that externalizing this ordering is the source of my issue, but have
yet to create a "minimum example" of the behaviour.
Here's what's happening :
When I re-order the items in the list via the drag/drop, I send a message to
change the sorted-by key over an async channel. (The key is not invisible, it's
data the user cares about, which is why I'm doing this instead of just using
local state).
The sortable component uses this sorted app-state in it's render function
directly (as part of om/build )
e.g.
apply dom/ul #js {:className "sortable" :ref "sortable"}
(map
(fn [item]
(if-not (= item ::spacer)
(om/build line-item item {:opts opts
:key :id} )
(sortable-spacer (second
(:cell-dimensions state)
(sorting-state (util/sorted-list items)
owner))
where sorting-state injects the spacer "on the fly"
(defn sorting-state [init-list owner]
(if (ux/dragging? owner)
(let [state (om/get-state owner)
drop-index (:drop-index state)
drag-id (:id (:dragging state))]
(util/insert-at ::spacer drop-index drag-id init-list))
init-list))
Re-ordering appears to work as expected, but every now and then, there's a
mismatch between the cursor as dereferenced by event handlers and the
parameters passed into the function by destructuring e.g. (defn line-item
[{:keys ... :as item} ...]
For example :
(defn line-item [{:keys [id name] :as item} owner opts]
(reify ...
... :onClick #(set-selected % id item )
with
(defn set-selected [e id item ]
(prn "selecting " id (:id @item) )
(om/update! item assoc :selected (not (:selected @item)))
When I click on the line item, id and the dereferenced id (:id @item) do not
match!
(this doesn't happen all the time, which is why I believe it's a timing thing
based on the moment between the component creation (where destructuring is
taking place) and the injection of the atom into the click handler.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: ANN: Om 0.3.0
Well at least I can know guess at the etymology : sql join leaps to mind, joining on a different "branch" of the state tree with keys from another branch. I didn't understand that until I read your tutorial. On Monday, January 27, 2014 10:35:54 AM UTC-8, David Nolen wrote: > om/join is conceptually quite cool, but it actually needs some serious work > as alluded - currently you're likely to run into some nasty surprises if you > really try to use it. The tutorials aren't going to proceed until this is > addressed sometime this week. > > > > David > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: ANN: Om 0.3.0
I'm a big fan of this new tutorial. It hi-lights some of the benefits of cursors, and I actually realize how I might use om/join suddenly :D -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: Om 0.3.0
Did you get this fixed Rudi?
If your project file requires om 0.2.3, then it was something with the
lein new command (which is now fixed).
I recommend manually changing the project file to require om 0.3.0 and then
don't forget to "lein cljscript clean" before recompiling (which I did).
On Saturday, January 25, 2014 1:41:54 PM UTC-8, Rudi Engelbrecht wrote:
>
> Hi David
>
> Thank you for a great tutorial!
>
> I really enjoyed working through your Tutorial on LightTable and Om.
>
> A note: In my environment the contact is being deleted when the
> contact-view has the following code
>
> (defn contact-view [contact owner]
> (reify
> om/IRenderState
> (render-state [this {:keys [delete]}]
> (dom/li nil
> (dom/span nil (display-name contact))
> (dom/button #js {:onClick (fn [e] (put! delete contact))}
> "Delete")
>
>
> and not when it is the following:
>
> (defn contact-view [contact owner]
> (reify
> om/IRenderState
> (render-state [this {:keys [delete]}]
> (dom/li nil
> (dom/span nil (display-name contact))
> (dom/button #js {:onClick (fn [e] (put! delete @contact))}
> "Delete")
>
> So the change to
>
> (put! delete @contact)
>
> has the effect of the delete button not working anymore.
>
> I will investigate further.
>
> Kind regards
>
> Rudi
>
> On Jan 25, 2014, at 11:16 AM, David Nolen >
> wrote:
>
> A few minor simplifications to the Om model in this release. A breaking
> change if you were using om.core/bind, om.core/pure-bind or om.core/read -
> these complications have been removed.
>
> There's also now a tutorial optimized for Light Table for people want to
> understand the Om approach to React without losing time cobbling together a
> working environment: http://github.com/swannodette/om/wiki/Tutorial
>
> Have fun!
>
> David
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
> For more options, visithttps://groups.google.com/groups/opt_out.
>
>
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM/Reagent Handling client/server synchronization
The way I understand React, (which is to say, very little), it actually should be perfectly fine to receive your state from the server, and simply let it override or merge into your current local state, because Om/React should only re-render to the DOM when there's an actual difference. (Meaning you don't have to manage "events" coming from the server and filter out your own changes). So you could implement this, not as a client receiving events, but actually just as a client receiving the entire app-state (depending on how big that actually is). You could even have multiple root nodes based on different cursors subscribed to different server-side state, and compose your application that way, I imagine. On Saturday, January 25, 2014 3:52:44 PM UTC-8, Joel wrote: > With Om it seems I could keep one "cloud" of state, before applying a change > I could make a sort of pub/sub or command pattern to update server and its > clients. I would need to make I ignore events I send, as I'd apply them to my > local state first. > > I'm curious how clojurescript can communicate with server, can I send code to > evaluate on the server, which would need to be sanitized of course, but that > doesn't sound difficult as clojure code is simple to traverse. > > I was excited reading about Korma as well, it sounds like another great way > to request data from the server and simply cleanse the request that's passed > in. Has anyone done this? > > > > On Saturday, January 25, 2014 5:34:08 PM UTC-6, David Nolen wrote: > > Sending changes, there's no clean hook to do this as of yet. But I think > > being able to log all state transitions might be useful so we'll see. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: ANN: Om 0.3.0
Ahh whoops. Forgot the clean step. The lein new project imported 0.2.3 for me. I assume that has been fixed then? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: Om 0.3.0
I was following along with this and hit an interesting "bug" The contact list delete button actually works "out of the gate" in the first example, (when its supposed to fail) and when I add the deref in the next step I get Uncaught Error: No protocol method IDeref.-deref defined for type om.core/MapCursor: [object Object] And that was with 0.2.3 and 0.3.0 (I tried both) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM/Reagent Handling client/server synchronization
I imagine it'd be a separate library to "add on" to Om, when desired. Something "compatible" in much the same way kioo and sablono are template addons. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Om Templating
... err , ninja'd.. @ Creighton -- Cool, I didn't know kinoo does the slurping part as well. Neat -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM/Reagent Handling client/server synchronization
On Friday, January 24, 2014 3:45:49 PM UTC-8, David Nolen wrote: > FWIW the latest changes to Pedestal 0.3.0 (still not officially released) > dictates much less with respect to the client. > Good to know. I hope they're also leveraging core.async .. they were at the forefront with their own messaging-style channels when they landed, but to my mind, core.async is the future, (and should be in everything :D ) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Om Templating
On Friday, January 24, 2014 3:16:17 PM UTC-8, Joel wrote: > Is there a way to convert html to Om/ClojureScript syntax easily? Or, is > there a way already to simply use some kind of templates that are closer to > html? > > J Well, there's two different plugins for component syntax, but I imagine that's not what you're looking for. Perhaps something akin to React's own JSX, I expect. You might get some leverage from using Enlive to parse the HTML into Enlive-form, and then output it for use with kioo (https://github.com/ckirkendall/kioo) .. which works with Om. I'm not sure if there's an alternative as yet. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM/Reagent Handling client/server synchronization
I'd also search around for some of the work done on core-async and web-workers. I'm sure I read of some successful implementations of client-server comms in that arena (on this forum). Pedestal is great, (although a bit intimidating for a functional-newb like myself).. OTOH, it's pretty much a full-featured stack. If you're looking to integrate ReactJS(Om/Reagent) with a server, it might be better to get something more pluggable. On Friday, January 24, 2014 3:37:08 PM UTC-8, David Nolen wrote: > Haven't thought it through but synchronization between client/server is > definitely something I'm interested in. > > > > On Fri, Jan 24, 2014 at 5:40 PM, Joel wrote: > > > > I Lisp'ed quite some time ago, so no longer an insider, although I do get the > gist of Om and Clojure particularly the immutable state. > > > > I was wondering if Om already (or could) be used for keeping state in sync > with the server as well as other clients. Maybe this has already been > "exampled", but curious if there's a demo of this. > > > > It sounds like the modification to the state is accessible by a clojurescript > program, so therefore you could apply these to the server-side state I'd > imagine, barring issues with "collisions". Anyway, if someone has already > thought this thru or blogged about it, I'd be curious. > > > > > J > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescrip...@googlegroups.com. > > To post to this group, send email to clojur...@googlegroups.com. > > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Trying to wrap my head around the latest Om API changes
Well, at the moment the code is a little scatter-brained, and I'm not sure I can make it work for 100% of the intended use-cases, yet. For one, I want to better support "collaborative" events -- for example, distinguishing drag-enter and drag-leave events requires tracking across multiple components. This requires coordination at the master component level which is currently missing. Additionally, as of 0.2.3, I'm noticing some effects from the differences between "render state" and out-of-render-loop states, which I'll need to account for. Those caveats aside: Here's the way it hangs together. Components are defined in one (or more) namespaces. Then there's the "ux" namespace, which is required by those wishing to get DnD features (and future "universal" features, such as "add item to selection") The Root component of the application calls (ux/setup-ux-master [app owner opts] ...) during will-mount. (ux/setup ...) creates some channels. One for putting drag-events onto, one for reporting bounds upwards, and a disperser (a mult over drag-events) so that we can direct drag events to interested listeners. When root om/builds sub-components, it just passes down the data that is created by ux in opts. Right now that's a bit hacky, but I hope I can alleviate some of that by using the new data locations (init-state, state, shared) in 0.2.3 When a sub-component is interested in receiving drag-events, it calls (ux/register [owner ... handler-fn] The handler function is for drag events that the sub-component is receiving. (Right now, this also reports bounds upwards, which I intend to separate out for readability/compos-ability) The neat part about keeping all this in the ux ns, is that we only need to look in the one file for where we're storing all this data (the channels etc). This makes changing any of that a little friendlier, and the components don't need to care (aside from having to call some functions in the right places) It also means I could potentially use ::qualified-keys for collision protection. (I plan on trying that out soon). ux/register finds the disperser multi-chan and taps it with a filter that only receives drag-events that are within the calling-components bounds, adding a (go..) loop with the handler-function it was passed in. The fact that every component controls it's own filter (via updating it's own :bounds on Did-Update) means we get targeted drag-events for "free". Unfortunately, we don't get drag-enter and -leave, which made me sad, because the current solution seems so elegant. The drag-start, drag-end, dragging functions are also in ux/ and are bound to the appropriate components with (om/bind ..) as usual. These update the local state of the owner where appropriate, and push an event on the command channel when "decision" states are hit (e.g. drag-end). I *could* create them with handler functions as parameters, but I figured I'd rather have a "command handler" at the Root component level to manage app-state. For me, I like having the logic of the components in the components, the logic of the application at the root level, and the logic of the orthogonal-user-interactivity in a separate namespace. Now, I have a specific application I was building this for - so this would need some work to be made truly "bolt-on". (there are assumptions about the names of refs, which'd have to be injected, for example). As an aside: In my application, the app-state revolves around a list of items. These items are displayed in multiple lists based on a filter, and sorted based on an attribute of the data. This means the "drop" handlers between the two lists simply set an attribute on the data, and React just puts them in the appropriate position of the relevant list in the next render pass automatically. On Thursday, January 23, 2014 1:52:58 PM UTC-8, David Nolen wrote: > It'd be a nice to get a detailed writeup about your approach if you have the > time and feel inclined :) > > > David > > > > On Thu, Jan 23, 2014 at 4:42 PM, David Pidcock wrote: > > > On Thursday, January 23, 2014 10:13:49 AM UTC-8, David Nolen wrote: > > > Om's current API more or less follows this line of thinking - components > > are machines. However both the opaque nature of machines and the lack of > > fine grained control around immutable value storage (app state wrapped in > > an atom) have their downsides. I want Om components to have knobs. So while > > a component designer may decide to split their state in a certain fashion - > > users of the components should be able to reconfigure this without the > > system falling apart. > > > > > I am enjoying the abi
Re: [ClojureScript] Trying to wrap my head around the latest Om API changes
On Thursday, January 23, 2014 10:13:49 AM UTC-8, David Nolen wrote: > Om's current API more or less follows this line of thinking - components are > machines. However both the opaque nature of machines and the lack of fine > grained control around immutable value storage (app state wrapped in an atom) > have their downsides. I want Om components to have knobs. So while a > component designer may decide to split their state in a certain fashion - > users of the components should be able to reconfigure this without the system > falling apart. I am enjoying the ability to add behaviours to components via merging data into local component state. It's quite handy when trying to achieve orthogonal separation of concerns. For example - one might have several components on a page. Perhaps their primary purpose is to display certain items in various ways. Perhaps you have a group of items you want to split into different lists based on classification rules. One way to do this is to extend your sub-components, or to wrap them in a bigger component that manages the communication between them. Using Om's opts, local-state, and shared, lets me put all the logic (and inter-component communication necessary) for drag-n-drop into a separate namespace, and then I can pull into the components the DnD behaviour, and implement the few handler functions for the stuff that's specific to each component's concern (e.g. mutate app-state on a drop). Now, I've been dwelling in OO/Imperative land for a long time, so I'm sure there are cooler ways to do all this.. but I'm having fun with it :D -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Om/React, Core.Async and some random musings
Hmm - Just read about adding Opts back in latest Om version. Now I'll have to consider which of the data/channels etc need to go into initial-state, state (for merging) and opts.. I'm really enjoying watching the evolution of Om. Just observing the design choices as they progress gives me some insight into React and also functional programming itself. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] OM: read - an experience report & some suggestions
I second this request. It took a little bit of re-thinking (perhaps because I'm still getting my head into this functional thing :D ). I tend to want to do stuff like this : (some-fn (om/read cursor :a) (om/read cursor :b)) but of course, I really need to do something like this (om/read cursor (fn [cursor] (some-fn (:a cursor) (:b cursor It's not the worst thing in the world, but the former would seem clearer to me. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Om/React, Core.Async and some random musings
Thanks! Also - updating to om 0.2+ will improve the readability of this, as it'll remove references to "opts" and will also allow the new "shared" global state (which will eliminate some boilerplate reference-passing). Another thing I think I need to do is to make "bounds" reporting hierarchical, so only the encapsulating component hears about bounds for it's sub-components. That would allow the actual sortable stuff to work out better (since I'd use the bounds of the draggable objects to calculate the current "next item", in case we have a heterogeneous list of drag-objects we're re-ordering in our sortable). On Tuesday, January 21, 2014 11:25:39 AM UTC-8, David Nolen wrote: > This is great stuff! :) > > > > On Tue, Jan 21, 2014 at 2:22 PM, David Pidcock wrote: > > > > Sure. I have a version @ > > > > https://gist.github.com/anonymous/8546161 > > > > Note - this is om 0.1.7 compatible. I have yet to update it to 0.2+ > > > > Also, I am still learning myself, so I'm not certain I'd call it "idiomatic" > of anything, yet. > > > > Many thanks to David Nolen for his example sortable (many of the functions > are lifted as-is from there). > > > > The main difference in this approach is that it's intended to be a "bolt on" > feature. The containing component (the "main app", if you will) just calls a > couple of functions during initial setup and update etc and it's all > externalized. > > > > > Subcomponents then "subscribe" for drag events within their bounds with > another function, and this allows us to drag and drop between different > components with the same event channels. > > > > Drop handlers use a "command channel" to send a higher level command back to > the main component, which mutates the app-state according to whatever > business logic you'd like. > > > > Theoretically, the drop handlers could mutate the state at the subcomponent > level, but I prefer to centralize this at the main-app, in case some kind of > inter-component coordination is required. It also means all the drag > functions can be re-used very easily. > > > > > There are no doubt many ways this could be improved, and I'm exploring > several options, including injecting pre-filtering logic at the main app > level so that I can support drag-exit and drag-enter style events. > > > > > > > > > > On Monday, January 20, 2014 10:16:02 PM UTC-8, vladislav p wrote: > > > @David P, > > > Would you be able to share your code samples on githubs or ghist > > > I am slowly venturingin in to this stack and would appreciate to see D&D > > and other examples showing idiomatic use with Om. > > > > > > thank you in advance > > > > > > > > > On Monday, January 13, 2014 6:23:44 PM UTC-5, David Pidcock wrote: > > > > Perfect. > > > > > > > > That worked wonders. I just had to thread the owner into the filter-fn, > > > instead of the bounds by themselves. Still learning to think > > > declaratively, obviously. > > > > > > > > No more channel churn. > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescrip...@googlegroups.com. > > To post to this group, send email to clojur...@googlegroups.com. > > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Om/React, Core.Async and some random musings
Sure. I have a version @ https://gist.github.com/anonymous/8546161 Note - this is om 0.1.7 compatible. I have yet to update it to 0.2+ Also, I am still learning myself, so I'm not certain I'd call it "idiomatic" of anything, yet. Many thanks to David Nolen for his example sortable (many of the functions are lifted as-is from there). The main difference in this approach is that it's intended to be a "bolt on" feature. The containing component (the "main app", if you will) just calls a couple of functions during initial setup and update etc and it's all externalized. Subcomponents then "subscribe" for drag events within their bounds with another function, and this allows us to drag and drop between different components with the same event channels. Drop handlers use a "command channel" to send a higher level command back to the main component, which mutates the app-state according to whatever business logic you'd like. Theoretically, the drop handlers could mutate the state at the subcomponent level, but I prefer to centralize this at the main-app, in case some kind of inter-component coordination is required. It also means all the drag functions can be re-used very easily. There are no doubt many ways this could be improved, and I'm exploring several options, including injecting pre-filtering logic at the main app level so that I can support drag-exit and drag-enter style events. On Monday, January 20, 2014 10:16:02 PM UTC-8, vladislav p wrote: > @David P, > Would you be able to share your code samples on githubs or ghist > I am slowly venturingin in to this stack and would appreciate to see D&D and > other examples showing idiomatic use with Om. > > thank you in advance > > > On Monday, January 13, 2014 6:23:44 PM UTC-5, David Pidcock wrote: > > Perfect. > > > > That worked wonders. I just had to thread the owner into the filter-fn, > > instead of the bounds by themselves. Still learning to think declaratively, > > obviously. > > > > No more channel churn. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Om/React, Core.Async and some random musings
Perfect. That worked wonders. I just had to thread the owner into the filter-fn, instead of the bounds by themselves. Still learning to think declaratively, obviously. No more channel churn. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Om/React, Core.Async and some random musings
Like the dims-chan you used in your sortable.. That was where I got the idea. So to explain a little more about the architecture... Root creates a drag-input channel, and a (mult) over that for subcomponents to tap. The drag sources put their events on the drag-input channel, and the interested listeners get the events cc'd to them. This lets any component on the page listen to any drag-source on the page. I went a step further and reasoned that sub-components would really only be interested in drag-events within their bounds... which led me to add a filter on the tap. So what you're saying is, if I make my filter predicate work directly with (om/get-state owner :bounds) then the filter would be dynamic? I will have to try that out. On Monday, January 13, 2014 1:19:45 PM UTC-8, David Nolen wrote: > Without diving too much into your code, I don't see why you can't just have a > channel that communicates bound changes which you save via om.core/set-state!. > > > David > > > > > > On Mon, Jan 13, 2014 at 4:14 PM, David Pidcock wrote: > > > > > Let me add that, profiling this in Chrome has shown a steady growth of the > number of ManyToManyChannel objects when I do a lot of resizing, but Garbage > collection does clean them up nicely. > > > > > > On Monday, January 13, 2014 1:10:15 PM UTC-8, David Pidcock wrote: > > > I've been playing around with Om recently, and started down a rabbithole > > towards a drag-drop implementation. > > > > > > In my (toy) application, I have a couple of lists of items which I want to > > drag between. Before stumbling on Om and React, I was using a > > goog.fx.DragListGroup, and listening to the events. But binding data back > > to sub-components of the app was starting to look onerous. > > > > > > > > Om to the rescue! > > > > > > The lists are in app-state and mutations on them cascade nicely to the > > sub-components. Great. > > > > > > So my first thought was to try to integrate DragListGroup somehow (after > > all - that code is already written). Unfortunately, React doesn't like DOM > > manipulation outside it's lifecycle (it's possible, but much harder to do > > in idiomatic Om). > > > > > > > > Fortunately, David Nolen threw a sortable example together. > > > > > > Building on that example, I now have my "master app" component creating > > some core.async channels, which it then passes down to sub-components. > > These components can register for drag-events within their visible bounds. > > > > > > > > So here's my problem : when the bounds of a component change (i.e. it get's > > re-sized), the existing channel still only delivers events to the old > > bounds. > > > > > > I 'solved' this by untapping the old channel, creating a new channel with a > > filter for the new bounds and listening to it. > > > > > > This seems .. unwieldy. > > > > > > ; state is either current or previous state , depending on whether this > > > ; is called from did-update or did-mount. > > > > > > (defn listen-bounds [owner state opts ref-node] > > > (when-let [container (om/get-node owner ref-node)] > > > (let [ dims (-> container gstyle/getSize gsize->vec) > > > disperser (disperser opts) > > > drag-chan (:drag-target-chan state) > > > new-bounds (bounds container) > > > track-fn (fn [evt] (om/set-state! owner :last-evt evt)) > > > ] > > > (if (= (:bounds state) new-bounds) > > > (do > > > (if (nil? drag-chan) > > > (create-listener disperser new-bounds track-fn) > > > drag-chan) > > > ) > > > (do > > > (when-not (nil? drag-chan) > > > (untap disperser drag-chan) > > > (close! drag-chan)) > > > > > > (om/set-state! owner :bounds new-bounds) > > > (let [new-drag-chan (create-listener disperser new-bounds > > track-fn)] > > > (om/set-state! owner :drag-target-chan new-drag-chan) > > > new-drag-chan) > > > ) > > > > > > > > > > > > (defn directed-event-chan [bounds] > > > (filter> > > > (bound-filter bounds) > > > (chan))) > >
[ClojureScript] Re: Om/React, Core.Async and some random musings
Let me add that, profiling this in Chrome has shown a steady growth of the number of ManyToManyChannel objects when I do a lot of resizing, but Garbage collection does clean them up nicely. On Monday, January 13, 2014 1:10:15 PM UTC-8, David Pidcock wrote: > I've been playing around with Om recently, and started down a rabbithole > towards a drag-drop implementation. > > In my (toy) application, I have a couple of lists of items which I want to > drag between. Before stumbling on Om and React, I was using a > goog.fx.DragListGroup, and listening to the events. But binding data back to > sub-components of the app was starting to look onerous. > > Om to the rescue! > > The lists are in app-state and mutations on them cascade nicely to the > sub-components. Great. > > So my first thought was to try to integrate DragListGroup somehow (after all > - that code is already written). Unfortunately, React doesn't like DOM > manipulation outside it's lifecycle (it's possible, but much harder to do in > idiomatic Om). > > Fortunately, David Nolen threw a sortable example together. > > Building on that example, I now have my "master app" component creating some > core.async channels, which it then passes down to sub-components. These > components can register for drag-events within their visible bounds. > > So here's my problem : when the bounds of a component change (i.e. it get's > re-sized), the existing channel still only delivers events to the old bounds. > > I 'solved' this by untapping the old channel, creating a new channel with a > filter for the new bounds and listening to it. > > This seems .. unwieldy. > > ; state is either current or previous state , depending on whether this > ; is called from did-update or did-mount. > > (defn listen-bounds [owner state opts ref-node] > (when-let [container (om/get-node owner ref-node)] > (let [ dims (-> container gstyle/getSize gsize->vec) >disperser (disperser opts) >drag-chan (:drag-target-chan state) >new-bounds (bounds container) >track-fn (fn [evt] (om/set-state! owner :last-evt evt)) >] > (if (= (:bounds state) new-bounds) > (do > (if (nil? drag-chan) > (create-listener disperser new-bounds track-fn) > drag-chan) > ) > (do > (when-not (nil? drag-chan) > (untap disperser drag-chan) > (close! drag-chan)) > > (om/set-state! owner :bounds new-bounds) > (let [new-drag-chan (create-listener disperser new-bounds track-fn)] > (om/set-state! owner :drag-target-chan new-drag-chan) > new-drag-chan) > ) > > > > (defn directed-event-chan [bounds] > (filter> >(bound-filter bounds) >(chan))) > > (defn create-listener [disperser bounds f] > (let [drag-target-chan (directed-event-chan bounds)] > (tap disperser drag-target-chan) > (go (while > (when-let [event ( (f event) > event > ))) > drag-target-chan > )) > > > So two questions : > 1. I couldn't tell if untapping a channel also effectively closes it. Is > (close! ..) necessary here? > 2. Is there some way to avoid this churn? Would using an atom in > (directed-event-chan [@bounds] get me a dynamic filter? > > > As an aside : A lot of the core-async tutorials use (go (while true ... > I haven't gotten into the implementation, but if all channels in a go loop > are closed, is that code still taking up memory somewhere? > > I erred on the safe side (perhaps at the expense of readability) by using > (go (while (when-let ... ) and returning the value of the last read from > the channel. When the channel returns nil upon close, this is guaranteed to > exit. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Om/React, Core.Async and some random musings
I've been playing around with Om recently, and started down a rabbithole towards a drag-drop implementation. In my (toy) application, I have a couple of lists of items which I want to drag between. Before stumbling on Om and React, I was using a goog.fx.DragListGroup, and listening to the events. But binding data back to sub-components of the app was starting to look onerous. Om to the rescue! The lists are in app-state and mutations on them cascade nicely to the sub-components. Great. So my first thought was to try to integrate DragListGroup somehow (after all - that code is already written). Unfortunately, React doesn't like DOM manipulation outside it's lifecycle (it's possible, but much harder to do in idiomatic Om). Fortunately, David Nolen threw a sortable example together. Building on that example, I now have my "master app" component creating some core.async channels, which it then passes down to sub-components. These components can register for drag-events within their visible bounds. So here's my problem : when the bounds of a component change (i.e. it get's re-sized), the existing channel still only delivers events to the old bounds. I 'solved' this by untapping the old channel, creating a new channel with a filter for the new bounds and listening to it. This seems .. unwieldy. ; state is either current or previous state , depending on whether this ; is called from did-update or did-mount. (defn listen-bounds [owner state opts ref-node] (when-let [container (om/get-node owner ref-node)] (let [ dims (-> container gstyle/getSize gsize->vec) disperser (disperser opts) drag-chan (:drag-target-chan state) new-bounds (bounds container) track-fn (fn [evt] (om/set-state! owner :last-evt evt)) ] (if (= (:bounds state) new-bounds) (do (if (nil? drag-chan) (create-listener disperser new-bounds track-fn) drag-chan) ) (do (when-not (nil? drag-chan) (untap disperser drag-chan) (close! drag-chan)) (om/set-state! owner :bounds new-bounds) (let [new-drag-chan (create-listener disperser new-bounds track-fn)] (om/set-state! owner :drag-target-chan new-drag-chan) new-drag-chan) ) (defn directed-event-chan [bounds] (filter> (bound-filter bounds) (chan))) (defn create-listener [disperser bounds f] (let [drag-target-chan (directed-event-chan bounds)] (tap disperser drag-target-chan) (go (while (when-let [event (http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: Om, a ClojureScript binding to Facebook's React
Ha! Just saw your Sortable example popup in Git! Very cool. On Thursday, January 2, 2014 4:00:45 PM UTC-8, David Pidcock wrote: > Very nice. Relatively easy to follow. Basically it's re-implementing the > drag-list behaviour in React. I had thought to re-use some existing code, > provided I could inform React that the DOM was changing. (This is the > approach used by the example in the fiddler, albeit with jquery instead of > goog.closure as the UI manipulation library) > > > I'm very interested to see what you do with this, in Om. > This example is complex enough that following along would most likely fill in > the conceptual gaps for me, that the TODO example lacks. > > > Again - inspiring work.. > > > -- David > > > On Monday, December 30, 2013 10:02:37 PM UTC-8, David Nolen wrote: > > From a React dev: > > https://www.khanacademy.org/preview/content/items/xfa03b103 > > https://github.com/Khan/perseus/blob/master/src/widgets/orderer.jsx#L6-L439 > > > > > I'm sure this can be adapted for Om. I may write up a simpler Om example in > the future. > > > David > > > > On Tue, Dec 31, 2013 at 12:43 AM, David Pidcock wrote: > > > On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: > > > Enjoy, > > http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ > > > > > > > > > > > > David > > > > I've been playing around with some basics. I'm still a relative n00b when it > comes to functional programming, and I've never looked at React before. > > > > Very cool stuff. > > > > I managed to get Om+React to display a list of items that are sorted by a > given key, and I have a content-editable span which updates the state of the > owner with new value of that key for a given item, and voila! the list item > moves to the correct position. (as expected) > > > > > Now here's the tricky part... > > I want to implement a drag-list, where I can drag-drop items into a new > position, and update the key based on the new position. I have that algorithm > working in a different project (using goog.DragListGroup) , but React does > not like you to manipulate the DOM outside it's knowledge. > > > > > I found this : > > https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ > > > > which lead to > > http://jsfiddle.net/LQxy7/ > > > > Unfortunately, I can't get this to work with Om. I am having trouble > navigating the data structures. > > > > How are "props" created/accessed? I followed the TodoMVC example, but that > seems to be using "state", which I am given to understand should be kept as > high in the hierarchy as possible (per the React recommendations). I tried > something like (:value (om/get-props this)) from within IRender, but that > doesn't work. Also : (om/get-props this [:items] ) (following the idiom > established by get-state. > > > > > I'm probably missing something obvious, so I thought I'd pop in here to see > if there's someone who can point me in the right direction. > > > > > > -- > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: Om, a ClojureScript binding to Facebook's React
Very nice. Relatively easy to follow. Basically it's re-implementing the drag-list behaviour in React. I had thought to re-use some existing code, provided I could inform React that the DOM was changing. (This is the approach used by the example in the fiddler, albeit with jquery instead of goog.closure as the UI manipulation library) I'm very interested to see what you do with this, in Om. This example is complex enough that following along would most likely fill in the conceptual gaps for me, that the TODO example lacks. Again - inspiring work.. -- David On Monday, December 30, 2013 10:02:37 PM UTC-8, David Nolen wrote: > > From a React dev: > > https://www.khanacademy.org/preview/content/items/xfa03b103 > https://github.com/Khan/perseus/blob/master/src/widgets/orderer.jsx#L6-L439 > > I'm sure this can be adapted for Om. I may write up a simpler Om example > in the future. > > David > > > On Tue, Dec 31, 2013 at 12:43 AM, David Pidcock > > > wrote: > >> On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: >> > Enjoy, >> http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ >> > >> > >> > >> > David >> >> I've been playing around with some basics. I'm still a relative n00b when >> it comes to functional programming, and I've never looked at React before. >> >> Very cool stuff. >> >> I managed to get Om+React to display a list of items that are sorted by a >> given key, and I have a content-editable span which updates the state of >> the owner with new value of that key for a given item, and voila! the list >> item moves to the correct position. (as expected) >> >> Now here's the tricky part... >> I want to implement a drag-list, where I can drag-drop items into a new >> position, and update the key based on the new position. I have that >> algorithm working in a different project (using goog.DragListGroup) , but >> React does not like you to manipulate the DOM outside it's knowledge. >> >> I found this : >> >> https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ >> >> which lead to >> http://jsfiddle.net/LQxy7/ >> >> Unfortunately, I can't get this to work with Om. I am having trouble >> navigating the data structures. >> >> How are "props" created/accessed? I followed the TodoMVC example, but >> that seems to be using "state", which I am given to understand should be >> kept as high in the hierarchy as possible (per the React recommendations). >> I tried something like (:value (om/get-props this)) from within IRender, >> but that doesn't work. Also : (om/get-props this [:items] ) (following the >> idiom established by get-state. >> >> I'm probably missing something obvious, so I thought I'd pop in here to >> see if there's someone who can point me in the right direction. >> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: Om, a ClojureScript binding to Facebook's React
On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: > Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ > > > > David I've been playing around with some basics. I'm still a relative n00b when it comes to functional programming, and I've never looked at React before. Very cool stuff. I managed to get Om+React to display a list of items that are sorted by a given key, and I have a content-editable span which updates the state of the owner with new value of that key for a given item, and voila! the list item moves to the correct position. (as expected) Now here's the tricky part... I want to implement a drag-list, where I can drag-drop items into a new position, and update the key based on the new position. I have that algorithm working in a different project (using goog.DragListGroup) , but React does not like you to manipulate the DOM outside it's knowledge. I found this : https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ which lead to http://jsfiddle.net/LQxy7/ Unfortunately, I can't get this to work with Om. I am having trouble navigating the data structures. How are "props" created/accessed? I followed the TodoMVC example, but that seems to be using "state", which I am given to understand should be kept as high in the hierarchy as possible (per the React recommendations). I tried something like (:value (om/get-props this)) from within IRender, but that doesn't work. Also : (om/get-props this [:items] ) (following the idiom established by get-state. I'm probably missing something obvious, so I thought I'd pop in here to see if there's someone who can point me in the right direction. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
