11–20 of 35 posts
I know very little about React, so this might be a dumb question. I looked at the source for the example and it looks very nice, but I noticed the DOM is built using constructs like (dom/div ...). Is it also possible to use something akin to hiccup's syntax like [:div ...]?
This should fix the innerHTMLstuff - https://github.com/vijaykiran/react-tutorial-om/commit/15281... Also, why clojurescript 2127 ? I thought 2120 is the latest stable version.
I know very little about React, so this might be a dumb question. I looked at the source for the example and it looks very nice, but I noticed the DOM is built using constructs like (dom/div ...). Is it also possible to use something akin to hiccup's syntax like [:div ...]?
As suggested somewhere else on this thread - try https://github.com/holmsand/cloact
so... React in clojurescript is great. the other bindings i have seen are pump [1], but as i'm new to lisp/clojurescript i struggled with some of the parallels. a tutorial comes welcome. somewhat aside- am i crazy for thinking React should bundle some sort of internal style processor? having your template and and your logic in the same place, in the same language, (cljs + react) seems to transcend the dirty feeling o…
Why would you want to bundle styles with your components? There is already a nice separation there, maybe you could give an example use case?
if styles were solved in a similar way i think you'd be able to get rid of the notion of a selector all together (though it would compile down to normal selector based css).
also, components would just be easier to grok and more portable.
Earlier quoted context omitted.
Why would you want to bundle styles with your components? There is already a nice separation there, maybe you could give an example use case?
maybe it's nice, but it's nice in the same way we've been separating HTML and JS for years, which React completely disregards. if styles were solved in a similar way i think you'd be able to get rid of the notion of a selector all together (though it would compile down to normal selector based css). also, components would just be easier to grok and more portable.
Does anyone else think the name is unfortunate? I can't imagine how difficult it would be to google "om".
Does anyone else think the name is unfortunate? I can't imagine how difficult it would be to google "om".
Earlier quoted context omitted.
maybe it's nice, but it's nice in the same way we've been separating HTML and JS for years, which React completely disregards. if styles were solved in a similar way i think you'd be able to get rid of the notion of a selector all together (though it would compile down to normal selector based css). also, components would just be easier to grok and more portable.
I can't see the parallels between js/html and css/html. React disregards the js/html because they acknowledge that there never really was proper separation. With css/html, at least to me, it seems like there is a clearer separation. Maybe I'm being shortsighted.
i guess the question i struggle with then is, what is so nice about that separation? and, could those problems not also be solved in JS?
Earlier quoted context omitted.
Why would you want to bundle styles with your components? There is already a nice separation there, maybe you could give an example use case?
maybe it's nice, but it's nice in the same way we've been separating HTML and JS for years, which React completely disregards. if styles were solved in a similar way i think you'd be able to get rid of the notion of a selector all together (though it would compile down to normal selector based css). also, components would just be easier to grok and more portable.
As long as the styling code could remain simple to update independently of the business logic, it would be great to have it all part of the same internally-consistent dev system.