Re: [ClojureScript] OM/Reagent Handling client/server synchronization
FWIW the latest changes to Pedestal 0.3.0 (still not officially released) dictates much less with respect to the client. On Fri, Jan 24, 2014 at 6:42 PM, David Pidcock eraz0rh...@gmail.com wrote: 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 jo...@harpsoft.com 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. -- 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] ANN: Om 0.3.0
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 -- 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] ANN: Cloact is now Reagent 0.2.0
Great stuff! :) On Fri, Jan 24, 2014 at 7:52 AM, Dan Holmsand holms...@gmail.com wrote: Cloact, a minimalistic interface between React.js and ClojureScript, is now called Reagent (the old name was bad in all sorts of ways). There is also a new little demo of how to implement undo for Reagent components here: http://holmsand.github.io/reagent/news/cloact-reagent-undo-demo.html The new project page is here: https://github.com/holmsand/reagent Cheers, /dan -- 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. -- 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
Heh, yeah I don't intend to add anything directly to Om for this, just interested in the types of solutions people come up with. Om is pretty tiny and I'd like to keep it that way. On Fri, Jan 24, 2014 at 8:18 PM, Moritz Ulrich mor...@tarn-vedra.de wrote: On Sat, Jan 25, 2014 at 12:37 AM, David Nolen dnolen.li...@gmail.com wrote: Haven't thought it through but synchronization between client/server is definitely something I'm interested in. Hopefully not for Om! :) I don't think Om should handle that sort of stuff - It might easily grow into a monolithic framework if not being careful. -- 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. -- 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] A bug in cljs.reader?
Known bug - http://dev.clojure.org/jira/browse/CLJS-677
On Sat, Jan 25, 2014 at 12:30 AM, tcr1...@gmail.com wrote:
Came across this issue today when attempting to read a keyword that starts
with a number.
(read-string {:42 \the answer\})
Cannot read property '0' of null
The source of the problem stems from the read-keyword function that uses a
symbol-pattern[1]:
(re-matches* symbol-pattern 42)
nil
Since Clojurescript does support these keywords the reader should too,
correct?
[1] [:]?([^0-9/].*/)?([^0-9/][^/]*)
--
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.
--
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 port of the Om tutorial
Nice. I do consider the non-modularity of `update-contacts!` here to be one of the big things I try to address in Om. The Reagent `update-contacts!` knows too much. In Om, it doesn't matter at all where :contacts lives in the app state, the Om contacts-view can still update it. David On Sat, Jan 25, 2014 at 1:50 AM, Jonas Enlund jonas.enl...@gmail.comwrote: Hi As an exercise I ported the Om tutorial to Reagent. It's available at https://github.com/jonase/reagent-tutorial I hope you find it interesting. Jonas -- 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. -- 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
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. On Thu, Jan 23, 2014 at 12:57 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote: Not true. React has exactly the same problem. There's no public way to get at component state deep in the render tree. Fair enough. I'm still in the local state is poison camp though. To be fair, React really doesn't implement component state as local state. Such a thing can't exist because components are virtualized objects which are only hydrated when they need to do computation. The implementation utilizes a global state map, precisely because such local state is poison: It's what necessitates removeChild and dispose mechanisms in other UI frameworks (essentially reference counting). The two distinctions relevant to component state are between 1) encapsulated and exposed state and 2) durable and ephemeral state. React's state model provides components with encapsulated, emphemeral state. Encapsulated meaning that other components can't reach in there and tinker with it. Ephemeral meaning it isn't permitted to be captured to be stored and if it is somehow lost, it's not a big deal because it can be recovered. The ephemeral nature of the data is somewhat intrinsic because the DOM is ephemeral: If you were to serialize your application and teleport it to another browser, you'd have to rebuild/recover the DOM's state. There is much DOM state that shouldn't be ephemeral, but we're stuck with it. However, there is much model/view state that should be ephemeral and we need that option. I'll quote Rich on encapsulation: [If] you have a notion of “private”, you need corresponding notions of privilege and trust. The fact that components are encapsulated is part of what makes larger apps even possible. It's the wrong default for values, but it's the right default for machines (which components are). With values, we can get pseudo-encapsulation with a deftype wrapper. With machines, we can get unencapsulation by other means... but that's a larger topic I won't go in to unless prompted. I haven't kept up with Om's API evolution, so I can't comment on how this line of thinking can/should influence the design, but hopefully thinking about these properties is useful. -- 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. -- 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
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 eraz0rh...@gmail.com 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 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. -- 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
On Tue, Jan 21, 2014 at 9:14 PM, kovas boguta kovas.bog...@gmail.comwrote: I understand all these mechanisms exist for a reason, but is there hope for simplifying things? The distinctions between :init-state and :state, and between :opts and get-shared are pretty subtle. Additionally, there is also the vanilla cljs way of defining constant global data, which people will think about reaching for. :init-state is an optimization and not strictly necessary. :opts is useful. om.core/get-shared leaves the door open for components requesting some global service without resorting to cljs.core/exists?. Point 1: the pathways to access the local state are very limited in Om, and seem likely to lead to complexity. For instance, passing data into the parent so that it can set the state of its child. Or having to manage channels to read/write to the local state via go loops on the owner. Unlike OO/React, there is no object graph to navigate in order to get access to the local state of some component. I fear for my render functions, if they have to be conduits for some deep subcomponent's local state update. Not true. React has exactly the same problem. There's no public way to get at component state deep in the render tree. Point 2: The APIs for app-state and local state are completely different, for ideas that are not that much different. They are both data for the pure rendering function; data which we want to be able to update from both within the component and from above it. application state and component local state are very different with respect to consistency. In principle, view-model data need not be much different from app-state data; the differences are: a) it cannot be co-located with app-state data, not because of clutter, but because there might be more than 1 component built from the same cursor position; and b) it needs to be initialized as the components are initialized. It should not be co-located if it is not something you intend to snapshot. There is no requirement that the view-model data be encapsulated in the component, or even that packets of view-model data correspond 1-to-1 with components. (One of the awesome things about Om is that the app-state data can be relatively freely reshaped into components, rather than the rigid 1-to-1 mapping in traditional MVC) Given these requirements, I think there is an alternative design, though the margin is too small to contain it. Definitely open to alternate ideas but I won't budge on the fundamental split: a) application state b) component local state c) side information I do think that that being to able force a child component to write it's state into a) instead of b) is an interesting direction to pursue and perhaps can shed some light on how a) and b) can conceptually unified. 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] Trying to wrap my head around the latest Om API changes
On Wed, Jan 22, 2014 at 6:34 PM, kovas boguta kovas.bog...@gmail.comwrote: On Wed, Jan 22, 2014 at 1:42 PM, David Nolen dnolen.li...@gmail.com wrote: om.core/get-shared leaves the door open for components requesting some global service without resorting to cljs.core/exists?. Not clear to me what that means. Is there more to it than get-shared is for things that don't change, :opts is for things that can change? With :opts you can chose to pass things down or not. Not useful for global information or services. Not true. React has exactly the same problem. There's no public way to get at component state deep in the render tree. Fair enough. I'm still in the local state is poison camp though. Hard to get at, and against the grain of the value that Om provides. Being able to hold the complete state in your hand, rather than scattered across implementation details, is awesome. In the Om model people can choose how they divide up their state. If you want to save everything in application state, fine. But many applications will not want to do this. That said, I think it's useful to be able to force a component to write its local state to some more durable location and this is what I want to explore. application state and component local state are very different with respect to consistency. I think I recall seeing a discussion about this, could you provide a pointer or re-summarize? Application state is only consistent during renders. Anything outside the render loop (event handlers, go loops) is not guaranteed to have a consistent picture of the application state. This not true for component local state, it's always consistent. The way I think about it is, look at atoms, refs and agents. Yes they are all a bit different, yet somehow it still feels like the same API. Similar deal with channels that having different buffers. It should not be co-located if it is not something you intend to snapshot. This is an interesting point. How useful are snapshots if you don't capture local state? I would expect that undo would bring back exactly back to the state I had before. Extremely useful. I don't need to save every mouse movement when I'm sorting a sortable. I just want to undo the actual sort states. 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] get-shared join
Yep, I'll keep playing around with om.core/join and see if we can make it worthwhile. David On Tue, Jan 21, 2014 at 10:08 AM, Ruslan Prokopchuk fer.ob...@gmail.comwrote: David, thanks for reply. I like idea of om.core/join and vote for it if one will not complicate things. Because in my current project I have some global app options which could be changed and are used in several places of component hierarchy. I know, it is cheap to merge them to components' props passing down render tree, but it is annoying to do by hand in many places, and I like possibility to make join in any subcomponent and to be sure that it will be updated properly. But I don't know how join with such behavior will complicate om or create danger for consistency. Your intuitions are correct. om.core/get-shared and om.core/join are not really related at all. om.core/get-shared is about accessing data global to an entire render tree that will never change. om.core/join is very experimental, I'm not sure what this functionality should look like yet. The idea is that you can compose component data out of smaller pieces of data in the application state. -- 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. -- 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
This is great stuff! :) On Tue, Jan 21, 2014 at 2:22 PM, David Pidcock eraz0rh...@gmail.com 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 DD 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. -- 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
Conrad,
Your understanding is mostly right, with the exception of :opts. :opts is
just a modular way to push side information down the render tree -
information that doesn't belong in application state, nor component locate
state. :opts can in fact change and perhaps people will find that useful.
However, most of the uses of :opts I've seen can and probably should be
replaced with :init-state and :state usage instead.
One thing you didn't mention is om.core/get-shared. Setting shared data via
om.core/root + om.core/get-shared allows shared values across the entire
render tree that will never change.
David
On Tue, Jan 21, 2014 at 3:43 PM, Conrad Barski drc...@gmail.com wrote:
Hi everyone, there are now four different ways to pass data from
parent-child components in the build function defined in the 0.2.3 library:
- Via the cursor
- Via the optional map, using on of three different map keys:
:init-state
:state
:opts
Let me take a stab to see if I can explain the difference between these
four, and if anyone knows if this explanation is flawed, let me know.
Let's assume we're buying socks through a web store:
If the data passed to the child is part of the main application state, we
do it via the cursor. For instance, our application state might contain the
fact that we've put two pairs of red socks into our shopping cart. If we're
rendering a component for each item in our shopping cart, the item for the
red socks would get passed a cursor into the main application state that
ends up pointing to a branch in this state containing something like
{:item_id 32423 :amount 2 :desc Red Socks}
If the component has to maintain some transient state and this transient
state has a default value, we set it via :init-state. For instance, if the
customer tries to purchase their socks, we might display a shipping
address component, with a submit button. But on top there might be a
checkbox called Same as billing address that is checked by default.
Therefore the component managing the checkbox might be given an :init-state
of {:same-as-billing true} which establishes this default state. If React
then decides to re-render this component, the :init-state in the re-render
will be ignored. Also, since the user hasn't hit the submit button yet,
we want to keep this state local instead of polluting our application state
(which is why we didn't use the cursor.)
The :state option is used to merge new state information into the child
component, triggered by the parent. For instance, if the shipping address
component is already visible, but the user has decided via another Om
component that they want to pay with bitcoin, the root application state
may now have a new key set inside it of {:payment-method :bitcoin} which
will trigger a rerender of the root component. As part of that, the parent
component would now set the :state key the shipping address component of
{:billing-address-available false} so that the Same as billing address
checkbox is disabled (since a bitcoin payment is pseudonymous and has no
physical address.)
Finally, if a component needs to be passed a value that will never change
through the lifetime of the component, we do it by passing in :opts. For
instance, our web store might have a component called fine-print, that's
instantiated in different parts of the store to display some
context-appropriate legalese. Since the text in this component may be
different in different parts of the store, but remains constant through the
life span of a given component, we can pass in the string of legal text via
:opts.
Anyway, I'd love to hear anybody's opinions as to whether this description
matches the behavior and intention of the latest Om changes.
--
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.
--
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: issue with build component types
On Sun, Jan 19, 2014 at 9:27 PM, kovas boguta kovas.bog...@gmail.comwrote: My workaround is to set! .-constructor of the object returned from build, but this is pretty ugly and requires additional bookkeeping, like creating unique objects to correspond to the tags. Is there a better way to do this? What's currently there is also pretty ugly but necessary until we can get some kind of patch into React itself. I don't really understand the extra bookkeeping beyond setting the constructor. Can you explain? 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: issue with build component types
Ok I think I see the problems you are encountering. But I don't see how this isn't solved by making the mutimethod return the right *function*. It's a little bit more work and it means you'll have to repeat an argument or two in your use of om.core/build but I think this is workable: (om.core/build (view data) data ...) Where view is a multimethod or protocol fn that returns the actual component constructing function. David On Sun, Jan 19, 2014 at 9:27 PM, kovas boguta kovas.bog...@gmail.comwrote: There seems to be a problem with using multimethods (and presumably protocols) as the function passed to build. In particular, lifecycle methods will not be properly invoked after the initial render. The cause of the problem is that build identifies the component type as the function passed to build (as I understand it) In my case, I want to use a generic multimethod to map my data to specific components: (defmulti make (fn [x args] (:tag x))) (defmethod make :component1 [x args] (reify )) (defmethod make :component2 [x args] (reify )) etc The result is that both component1 and component2 will end up with the same component type. Which means that if I swap component1 with component2 in my app-state, render will be called but mount and unmount will not be, because React will think it was the same component. My workaround is to set! .-constructor of the object returned from build, but this is pretty ugly and requires additional bookkeeping, like creating unique objects to correspond to the tags. Is there a better way to do this? -- 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. -- 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
On Mon, Jan 20, 2014 at 6:20 PM, kovas boguta kovas.bog...@gmail.comwrote: I'm having a hard time using read. I find myself using it in 2 places: 1. Inside the event handler, I want to read, optionally do something with the value (typically assoc/dissoc), and put it on a channel. 2. Inside a go block initialized during will-mount, same story. The problem is that I do a read, pass the value along, and then when the other end of the channel wants to do an operation, I get the Cannot manipulate cursor outside of render phase error. If I turn the value into a string before putting it on the channel, I don't get the error. Is this a laziness issue? A bug, or desired behavior? In any case, I find it confusing. Now, here is a leading question: What is the difference between a cursor and a reference type? Instead of having both (value x) and (read x f), why not just @x? As this question suggests, I also don't understand why both value and read are necessary. Om attempts to address consistency issues. Just because you have a cursor doesn't mean you actually have the most current value in the application state, thus read. read is always guaranteed to give the latest value. But if you read only to put the cursor back into an asynchronous channel of course all bets are off! To me pipelining cursors into a series of asynchronous operations just doesn't make any sense, you're bound to end up in an inconsistent state. Once this is clear then I think we can have discussion about potential solutions. Whether we should support deref is orthogonal. And even if we do `value` might still be useful. 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: issue with build component types
On Mon, Jan 20, 2014 at 6:32 PM, kovas boguta kovas.bog...@gmail.comwrote: On Mon, Jan 20, 2014 at 1:58 PM, David Nolen dnolen.li...@gmail.com wrote: The issue is that Om is extremely lazy, we don't even know what we have until we see that we need to update. I don't understand the issue here, unless its a quirk of React. If React is rendering the component, that means shouldComponentUpdate has returned true and we have a concrete component in-hand, no? Is the problem that it checks the component type before asking shouldComponentUpdate? Pretty much. -- 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 see. I'll consider relaxing om.core/read to return data instead of another cursor. This should make it easier to work with and you can always hold onto the original cursor for doing app state transactions. On Mon, Jan 20, 2014 at 6:46 PM, kovas boguta kovas.bog...@gmail.comwrote: On Mon, Jan 20, 2014 at 5:36 PM, David Nolen dnolen.li...@gmail.com wrote: Ok this sounds like an interesting problem :) Om attempts to address consistency issues. Just because you have a cursor doesn't mean you actually have the most current value in the application state, thus read. read is always guaranteed to give the latest value. But if you read only to put the cursor back into an asynchronous channel of course all bets are off! So is the recommendation to put the cursor itself on the channel, and then delay read until the last possible moment? To me pipelining cursors into a series of asynchronous operations just doesn't make any sense, you're bound to end up in an inconsistent state. The reason I want to do this is client/server communication. Eventually some data needs to escape your application, and yes this implies that the remote system will see state that is not completely up to date. In this context, I want to use a (short) sequence of go blocks to process the data as its getting funneled towards the server connection. -- 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. -- 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 - issue with props containing functions
On Sat, Jan 18, 2014 at 9:47 AM, Samuel Aaron samaa...@gmail.com wrote: OK, I looked into this. First I was wrong about apply, I was a bit tired when I wrote that, apply works fine in this instance because the dom macros are also functions. Oh, interesting - that makes complete sense. Out of interest what's gen-react-dom-fns for? Is that just some remains of experimentation or does it have other uses? It generates functions that call React.DOM.tag so that you can use apply. I told you I was tired :) 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: OM - issue with props containing functions
This is not necessary.
On Fri, Jan 17, 2014 at 5:47 PM, Vijay Kiran m...@vijaykiran.com wrote:
Shouldn't this :
(dom/h1 nil (:title data))
be:
(apply dom/h1 nil (:title data))
./Vijay
--
http://vijaykiran.com
On Friday, January 17, 2014 11:28:54 PM UTC+1, Sam Aaron wrote:
Hi there,
I was playing about with Om and ran into an issue when attempting to put
a function call inside a prop. Here's a minimal app:
(defn subdiv-color []
(rand-nth [black green blue red]))
(def app-state (atom {:title Testing Testing
:subdivs [subdiv1
subdiv2]}))
(defn render-subdiv [content]
(dom/div #js{:style #js{:color (subdiv-color)}} content))
(defn main-div [data owner]
(om/component
(dom/div nil
(dom/h1 nil (:title data))
(apply dom/p nil
(map render-subdiv (:subdivs data))
(def r1 (om/root app-state main-div js/document.body))
(js/setTimeout #(swap! app-state assoc
:title 1 2 3...)
1000)
On the first render, everything is hunky-dory. However, when the timeout
function triggers swapping the state, the second render blows up with:
Error while invoking `findComponentRoot` with the following ancestor
node:
body…/body
react.js:8813
Uncaught Error: Invariant Violation: findComponentRoot(...,
.r[hn4d].[1].[0]): Unable to find element. This probably means the DOM was
unexpectedly mutated (e.g. by the browser).
react.js:13161
Am I doing anything obviously wrong? If I replace the call to
subdiv-color to black everything works great. However, I'd really like to
be able to modify the props based on some logic.
Sam
---
http://sam.aaron.name
--
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.
--
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] How to manage state
I don't see the problem with flowing layout information down the tree. David On Wed, Jan 15, 2014 at 8:55 AM, Ruslan Prokopchuk fer.ob...@gmail.comwrote: I'm struggling for best solution in the following case: I have component representing svg node with some content which has to be centered in it and having some other properties derived from node dimensions. To achieve this I created listener for window resize which update state of component with necessary calculations results. In render some of them are passed to subcomponents as opts. Subcomponents have their own state holding coordinates because of drag support. So, problem is that I need these coordinates 1) snap to some positions 2) update app state with ids of that positions positions coordinates are calculated on window resize in parent component. I can make all calculations and update in subcomponents render, but this is not good, right? Can somebody point me in right direction? If my description is not specific enough, gist is here: https://gist.github.com/ul/8436521 P. S. Any comments about bad smelling code which is not covered by question also are welcome! -- 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. -- 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] How to manage state
It's ok to update component local state during render via om/set-state!, I don't see a good use case for updating global application state from render. david On Wed, Jan 15, 2014 at 9:09 AM, Ruslan Prokopchuk fer.ob...@gmail.comwrote: David, but is it ok to update component app state in render? My knowledge about Om/React is still very incomplete, so I don't understand fully how things should be organized. -- 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. -- 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] Fun map over keyword
clojurescript.net is a fork that can bootstrap to JavaScript. It's pretty disconnected from mainline ClojureScript development. David On Wed, Jan 15, 2014 at 1:04 PM, Ruslan Prokopchuk fer.ob...@gmail.comwrote: I can't figure out version which is used here http://www.clojurescript.net/ but it seems about a year old after looking on files at github. -- 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. -- 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] Confusion about accessing arrays using Om cursors
An oversight, fixed in master. Let me know if it works for you. If it does I can cut another release. On Tue, Jan 14, 2014 at 4:55 AM, Alexander Solovyov alexan...@solovyov.netwrote: I have a similar problem, I have extended string to be able to use it as a cursor: (extend-type string ICloneable (-clone [x] (js/String. x))) but I can't `update!` it, since it does not implement ITransact. I would love to be able to implement it, but it requires current state and a path, which appear as a parameters to `to-cursor*`, but are not exposed in any other way. So I'm unsure about what should I do. I don't want to give more than a string to my component: I could wrap a string in a map when passing it, of course, but will it be able to update? I don't think Om will be able to resolve such indirection. Any thoughts? -- 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. -- 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 : Passing parameters
There's a couple of ways to do this depending on your goals - but yes that
works.
On Tue, Jan 14, 2014 at 2:02 AM, clojure.u...@gmail.com wrote:
On Tuesday, January 14, 2014 11:42:45 AM UTC+5:30, David Nolen wrote:
There are plenty of simple components that don't need :opts. If you have
a better idea I'm all ears :)
On Tue, Jan 14, 2014 at 12:48 AM, clojur...@gmail.com wrote:
On Tuesday, January 14, 2014 11:09:23 AM UTC+5:30, David Nolen wrote:
Currently arbitrary parameters are passed via the :opts field in the
third argument to om.core/build. The examples in the repo demonstrate this
as well as the linked TodoMVC example.
On Monday, January 13, 2014, wrote:
Hi!
I am sure this is a stupid question and I apologize in advance!
How do we pass parameters to a component using om ?
Do we instead pass a path into the application state (atom) ?
Thanks in advance
--
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.
Thanks, I saw the opts field but found it a bit annoying especially when
you think every reusable component would be using it.
Still, I have loved om so far.
Thanks for this great work!
--
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.
:) still at the early stage of learning clojurescript/clojure and with a
lot of baggage from Java :-(
I am trying to create a bootstrap/tab component which I think should take
an vector with each element describing a tab
{:id home :title Home :content some-other-component }
So is this the recommended approach.
(defn tab
[app owner opts}]
())
and usage would be
(om/build tab app {:opts {
:active home
:tabs { }})
Thanks for all the help!
Really appreciate it!
--
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.
--
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] ANN: core.match 0.2.1
The only significant change is the bugfix MATCH-92, keywords with dots now supported. http://github.com/clojure/core.match -- 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] Guide to the ClojureScript Analyzer Compiler
I think Light Table, Clojure, and ClojureScript users will find this guide informative: http://swannodette.github.io/2014/01/14/clojurescript-analysis--compilation/ Cheers, 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] ANN: Cloact, yet another React wrapper for ClojureScript
On Mon, Jan 13, 2014 at 1:39 PM, Dan Holmsand holms...@gmail.com wrote: On 13 jan 2014, at 18:41, Bob Hutchison hutch-li...@recursive.ca wrote: I’m running in my browser, right now, a function that updates the render state and React is given the opportunity to redraw before the function continues (i.e. it re-renders right after the swap!). This is certainly within the rules. If you have multiple atoms that need to be updated then you’ll potentially see React re-render between each atom update… i.e. there will be React renders where the atom values are uncoordinated/inconsistent (possibly doing silly stuff on the screen, momentarily at least). I can imagine some very crude techniques to prevent this, do you know any good ones (beside putting all state in one atom (which, personally, I had been planning to do anyway))? Aah, I see. That is a very good question: most of the time you shouldn't see any inconsistent output, since React normally batches updates – but only in React's own event handlers. There are ways around that, but none of them are very attractive... FWIW, this is something I wanted to solve in Om. Application state updates are *always* batched, rendering always occurs on requestAnimationFrame (where available), and there's some basic enforcement logic around trying to update the app state from event handlers to work around inconsistency. 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 : Passing parameters
Currently arbitrary parameters are passed via the :opts field in the third argument to om.core/build. The examples in the repo demonstrate this as well as the linked TodoMVC example. On Monday, January 13, 2014, wrote: Hi! I am sure this is a stupid question and I apologize in advance! How do we pass parameters to a component using om ? Do we instead pass a path into the application state (atom) ? Thanks in advance -- 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 javascript:;. To post to this group, send email to clojurescript@googlegroups.comjavascript:; . 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] om : Passing parameters
There are plenty of simple components that don't need :opts. If you have a better idea I'm all ears :) On Tue, Jan 14, 2014 at 12:48 AM, clojure.u...@gmail.com wrote: On Tuesday, January 14, 2014 11:09:23 AM UTC+5:30, David Nolen wrote: Currently arbitrary parameters are passed via the :opts field in the third argument to om.core/build. The examples in the repo demonstrate this as well as the linked TodoMVC example. On Monday, January 13, 2014, wrote: Hi! I am sure this is a stupid question and I apologize in advance! How do we pass parameters to a component using om ? Do we instead pass a path into the application state (atom) ? Thanks in advance -- 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. Thanks, I saw the opts field but found it a bit annoying especially when you think every reusable component would be using it. Still, I have loved om so far. Thanks for this great work! -- 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. -- 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: React Component Types and diffs
Doesn't have a detrimental effect on their diff algorithm, if the component type changed they would destroy DOM nodes. On Sun, Jan 12, 2014 at 6:04 AM, Dave Sann daves...@gmail.com wrote: I am just starting to take a look at om. I downloaded the chrome react developer tools to look at the structure (found here: https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi ) I notice that the components that om creates are all of Type Unknown. Normally, I think that this would have a detrimental effect on their diff algorithm - because they do not diff different Types - but here all types are the same. Am I correct is saying that this is prevented by the implementation of shouldComponentUpdate in the Pure React class? thanks Dave -- 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. -- 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] Cloact 0.1.0 - Yet another React wrapper for ClojureScript
On Sun, Jan 12, 2014 at 8:50 AM, Peter Taoussanis ptaoussa...@gmail.comwrote: It's been my experience that this kind of snapshotting is generally trivial (order of a few lines), quite simple, and usually something I'd want to be doing manually anyway since usually not _all_ state is or should be subject to undo and/or tracking (non user-induced state pushed from the server, for example). In Om you will be able to pick what you want to snapshot. But I'm planning on providing a higher level api which will provide some interesting facilities :) Anyway, I do find the flexibility of choosing how+where state is stored to be a plus in practice, especially during prototyping stages and when migrating from an existing code base. You have the same flexibility in Om. Cloact just provides more admittedly nice sugar. The other option in Cloact is to use a single atom approach, but then you have mixed universe of snapshottable components and ones which aren't. I'm quite happy with having that flexibility since it allows me to make trade-offs as/when I need them. Then I won't use your components :) Also a model that emphasizes local state like this, which React suffers from as well, can not leverage as many rendering optimizations in the future as Om. I'm curious what you have in mind here and why you're describing it as local state. If I've understood React's diff algo correctly, it seems so long as we're handling our dirty/not-dirty marking accurately, we're subject to all optimisations, always. Since the atoms are immutable and their comparisons done as identity checks, I'm not seeing how much room there'd be for improvement driven by ClojureScript's side? If you read up on React's diff'ing algorithm you'll see there are some missed opportunities. In Om we will always know what's changed and precisely how it's related to what the user sees so we can drive React's diff'ing algorithm much better. 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: [Q] several questions on Om/Clojurescript
I didn't go that far because if it doesn't work under :simple I don't see how it could possibly work under any other settings. On Wed, Jan 8, 2014 at 10:43 AM, vladislav p vpapa...@gmail.com wrote: Thank you, I will look at that if you comment out completely out of the project.clj and app.cljs all references to dojo, where you able to reproduce the problem where if the compilation mode is set to :advanced , the sample does not work ? On Wednesday, January 8, 2014 9:49:22 AM UTC-5, David Nolen wrote: It appears that you're missing some dependencies required for Dojo to function. Dojo uses a function define which is not included in any of the Dojo libraries you've included. David On Wed, Jan 8, 2014 at 2:16 AM, vladislav p vpap...@gmail.com wrote: Hello David, thank you Here is the project to test on https://github.com/vladp/cljs_om_dojo -- 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. -- 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, a ClojureScript binding to Facebook's React
Yeah I cannot reproduce this. On Fri, Jan 3, 2014 at 12:24 PM, Dave Dixon dave.d.di...@gmail.com wrote: On Friday, January 3, 2014 9:11:34 AM UTC-8, David Nolen wrote: Then need more information., need a link to a minimal project where you're experiencing this problem. I think this is a local lein problem, not something specific to the om project. Just created an empty project using lein new mies, tried to build and got the same error. I'll try clearing out my local repo, please let me know if there are any other suggestions. Thanks. Dave -- 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. -- 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] :output-file vs :output-to (minor)
I wasn't even aware of :output-file to be honest. Ticket + patch welcome.
Thanks,
David
On Thu, Jan 2, 2014 at 9:39 PM, Timothy Pratley timothyprat...@gmail.comwrote:
./bin/cljsc hello.cljs '{:output-file foo.js}'
fails
The problem/fix is straightforward:
(apply add-dependencies all-opts
- (concat (if (coll? compiled) compiled [compiled])
+ (concat (if (satisfies? IJavaScript compiled) [compiled] compiled)
However I'm not entirely sure what the distinction is as to why you would
use one over the other (maybe the :output-file should be removed?).
Let me know if you want a ticket/patch for this and if you have a
preference.
Regards,
Timothy
--
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.
--
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] Allow more google closure options to be set
Looks OK to me. JIRA Ticket + patch please, thanks! David On Thu, Jan 2, 2014 at 8:38 PM, Ivan Willig iwil...@gmail.com wrote: Hi list, While I was messing around with ClojureScript and nodejs this week, I noticed that the Google Closure compiler complains when JavaScript reserved words are used. Newer versions of JavaScript engines allow reserved words (like static, class) to be used as object properties. The Closure Compiler knows this and does not complain when you set the language_in option to the correct version of JavaScript. I have opened a PR that allows you to set the language_in and language_out options. I have never contributed to clojurescript, so please tell me what I did wrong. :). I know submitting a patch might be easier, but I figure a github PR is better for feedback. https://github.com/clojure/clojurescript/pull/31/files Thank you Ivan Willig -- 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. -- 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
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 eraz0rh...@gmail.comwrote: 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 cloj...@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/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] Re: ANN: A Tricon Editor (Om Demo)
On Mon, Dec 23, 2013 at 5:10 PM, Conrad Barski drc...@gmail.com wrote: I should add I found Om very easy to work with (even in the pre-alpha state) and liked the major design opinions. The cursor + single state atom approach feels like an improvement over the React.js approach of emphasizing separate state storage for each component. I'm actually going to pursue optional separate state storage per component. This is useful if you want the incoming data to remain true to the real model and you like to put transient app specific state information elsewhere. This precisely why people use Model object's in MVCs, they allow you to encapsulate both the properties that represent the real data and side or transient app specific information. But people can chose to keep putting transient state information into the app state atom - it does allow you to capture transient states - this might turn out to be more useful than I can see right now particularly in the case of undo/redo operations? The only (rather small) drawback I encountered to this design is that sometimes the info in the cursor variable is an out-of-date version when I needed to access it, which is easily resolved by making sure to access the state only from within the update! function in those cases. (I haven't fully wrapped my head around the behavior of the cursor yet, so this confusion might disappear once I get more familiar with it.) This is a wart that I'm considering how to remedy. In my experience there are two big sources of this so far - go loops that you set up when your application mounts, and improper communication of change in the face of operations that move children nodes between one app state and the next (insertion, deletion, prepend, etc). If you don't handle this then you'll have items with stale paths. I think both cases are should be straightforward to address from Om such that users won't find it a common occurrence. Feedback welcome on any and all of this. 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] ANN: Om, a ClojureScript binding to Facebook's React
Currently React is included, this is likely to change and I will put React into it's own jar. On Fri, Dec 20, 2013 at 1:10 PM, Samuel Aaron samaa...@gmail.com wrote: On 20 Dec 2013, at 18:07, Tim Visher tim.vis...@gmail.com wrote: Is anyone aware of any specific reason(s) why symlinking om is a bad move? Transitive dependencies? Ah, excellent point, although Om currently only depends on cljs and clj. Sam --- http://sam.aaron.name -- 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. -- 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.
