I look forward to further understanding from my mistakes :)
Thank you.
ClojureScript+Reagent combination is a whole new level of thinking.
Absolutely convinced there is something big happening here with front end
development.
On Wed, Jan 28, 2015 at 2:29 PM, Mike Haney wrote:
> Don't be embarr
Don't be embarrassed- even if you think it's over engineered or won't work out
or whatever, you still tried something different - that's more than 90% of
people can say. I've been curious about your approach since you first
mentioned it, even though I wondered about its feasibility. I'm glad y
So I was supposed to have done this one the weekend but my 20 month old baby
girl objected.
I've finally managed to clean up the project and comments so that it is
understandable to others.
It's a learning project that has taught me:
1) the importance of Real FP (as opposed to sprinkling FP p
actually I realize now why the virtual dom is so cool in an FP paradigm
like ClojureScript: it simply orients you toward data and UI state and you
never have to even map back to the DOM ...
having said that, I bet that I can find a similar way to achieve the same
purpose without the magic of virtu
sure, it's work in progress, and for now showing use of D3 widget written
independently (using D3's own reusable component pattern) and simply
hooking into the state layer (which holds the data for the chart as well as
the pan/zoom of the brush on the chart) which it is then rendered from (by
the
Well, Reagent and Om will trigger the renders for you as well, and even batch
renders.
What sounds novel about your approach is doing the same thing for canvas and
webgl. Are you saying you have a library that does this for the dom, canvas,
and webgl all at once? That I would be interested in
The only thing novel to me (vs my own way) is that after updating state I
don't have to explicitly call render on the corresponding element(s) ... it
guesses by computing a diff but I am not sure what that buys me besides
beautiful functional code ...
On Wed, Jan 21, 2015 at 5:23 PM, Mike
Always glad to help.
Probably the biggest caveat with React is that you have to break old habits of
trying to directly manipulate the DOM, and be careful with other libraries like
jQuery that directly manipulate the DOM. It is possible to integrate things
like jQuery components with React, but
Ah. Making things easy, with some magic. I wonder what the caveats are.
I appreciate your answer. It's the same I got from my CTO/mentor, who is
very psyched about Reagent. I wonder what gotchas exist beneath all this,
but that's work for me to catch up with React.
Thank you very much Mike! nice
The short answer is that React is doing the heavy lifting for you.
Conceptually, you can just think of it as your app rendering the entire DOM on
every state change. It is a very functional approach, because you can think of
rendering as a pure function that takes your app state as input and r
<>
Maybe a dumb question, but I'm trying to bridge two worlds.
In one world, I have an optimized data structure for holding state of the
UI (on app, component and individual element level) including data and
properties specific to each element which I update (explicitly mutate) and
from which th
11 matches
Mail list logo
