On Sunday, November 2, 2014 10:47:13 AM UTC-6, Colin Yates wrote: > (om newbie, but getting less so :)) > > [overhead] > Is there any overhead for a react component at runtime? If I have a single > component which emits a bunch of <li>, is there any cost to having each <li> > be an instance of a component which emits that <li>? > > [transform cursor] > Is it OK to transform the cursor that is sent to a child component? > > For example, in my app-state I have a property "left-nav-expanded? :bool". > This is consumed by a generic "nav" component which wants an "expanded?" > property. At the moment I have the parent component do something like > "(om/build nav (assoc app :expanded? (:left-nav-expanded? app))". Is that > allowed? I want the expanded to be app state not component state BTW. > > Another example of this is I have a selected-id and I want the table to add a > "selected" class to the relevant row. Again, I want the selected-id to be > part of the app-state (as it needs to be preserved between sub-pages) so the > table has the selected-id property and the row components receive data > containing "selected?". This does mean every row gets "processed" when the > selected-id changes, which is making IE8 really quite slow unfortunately but > I don't want to store "selected?" in the app-state on the row as the list in > app-state is domain specific not UI specific. Is the idiomatic approach to > add a "selected?" on each item in the list in app-state? > > [Emit only components necessary or use "display" to show/hide components?] > Are there any discussions on the benefit of including (in om/root) all > components but using display:none to hide the deselected ones over only > including the current component? > > There are obvious benefits in terms of UI state like scrolling position being > preserved when using display:none but are there any performance > considerations? If only emitting the components being used then the om > lifecycle events are very useful for hooking in to to update the app-state > for example so app-state can only represent the current working set if that > is what you want. > > If it helps the app will only show maybe 10% of the components at any one > time. > > At the moment, in IE8, using the above approach (of decorating the cursor) to > select a row takes about a second on a table with 100 rows in it :(. It also > takes a few seconds to draw the whole table when changing pages. I haven't > profiled it yet using show/hide. > > Hope that makes sense and thanks!
<div><p>I'm not knowledgable enough to answer your questions definitively. But I think the <a href="http://swannodette.github.io/todomvc/labs/architecture-examples/om/index.html"; target="_blank">om todo mvc app</a> is worth studying. For example, the "item" component <a href="https://github.com/swannodette/todomvc/blob/gh-pages/labs/architecture-examples/om/src/todomvc/item.cljs#L67"; target="_blank">renders only an "li" tag</a>, yet the performance is <a href="http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/"; target="_blank">excellent</a>. I haven't done any of my own testing or benchmarking, but I feel comfortable just from seeing the performance of the todo mvc app that if there is any overhead with this approach, it's surely very minimal. I've never seen any recommendations to avoid this.</p> <p>The todo mvc app also demonstrates several of the specific techniques you're asking about, like <a href="https://github.com/swannodette/todomvc/blob/gh-pages/labs/architecture-examples/om/src/todomvc/app.cljs#L58"; target="_blank">transforming cursors</a> and <a href="https://github.com/swannodette/todomvc/blob/gh-pages/labs/architecture-examples/om/src/todomvc/item.cljs#L64"; target="_blank">generating css classes for rows from values in app-state</a>. These techniques seem perfectly reasonable to me.</p> <p>in IE8, try clicking "benchmark 1" <a href="http://swannodette.github.io/todomvc/labs/architecture-examples/om/index.html"; target="_blank">here</a>, and then clicking the "toggle-all" icon on the left side of the header row. In modern browsers, this is extremely fast. Is it slow in IE8? If not, I'd suggest comparing your strategies to those demonstrated in the todo mvc app and trying to identify what your bottleneck might be. Beyond that, from my perspective at least, it's much easier to (try to) be helpful if you can provide a a minimal code example that demonstrates the poor performance you're describing.</p> </div> -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
