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
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
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
, 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
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
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,
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
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
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
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
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
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
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.
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
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:
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.
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
701 - 739 of 739 matches
Mail list logo
