Abstracting your components ... ?

[Bryan Ray]

How far do you take your component abstractions? And would anyone be willing to post some common components that they tend to use on their applications? Or perhaps a component that they've got on a single application that they've found to be extremely useful?

For some reason, most of my ideas of a component revolve around a specific "page" (ie, input forms, displaying data for a specific model, displaying collections of models). This leads me to believe that I may not be thinking about components correctly, or perhaps that I can leverage them in better ways.

I did manage to put together a "Router" component; with the help of paquitosoft's articles, but not I'm curious ... what other components should I be thinking about while building out a full ractivejs site?

Thanks in advance.

[Aris Alexis]

When I think of component I think of a reusable item on my page. For example a usercard component that shows a tiny image of the user with some stats about him that may appear in search results or in user profiles etc. in general i make a component whatever encapsulates html with js events and i try to isolate it as much as possible so that's it's reusable

[Alejandro Gómez]

I was looking for a post similar than this.

I've seen some components in the official page of Ractive, but there are not as much as with React.

Is there a way to encourage the community to create more components ? Is there a place to list all of them together ?

I find Ractive a great tool for UI development, as long as this doesn't manage that much data (I've worked with Ractive over 1 year and I've seen how slow it is with a lot of components alive)

Still this can move forward on the same direction as libraries like bootstrap or semantic ui.

What do you think ?

[Rich Harris]

This is a major communication failure on our part – Ractive has always been about components (ignoring its first couple few months of existence, when it wasn't much more than an experiment), but the tutorials, documentation and examples have never really reflected it. Personally I always use single file components because I find it logical to put related styles, markup and behaviour together.

 > Is there a way to encourage the community to create more components ? Is there a place to list all of them together ?

There was some tangential discussion of it in this issue: https://github.com/ractivejs/ractive/issues/2271

> and I've seen how slow it is with a lot of components alive

Yeah. This is something that should be much improved with 0.8. Once that's out, it would be great to focus on improving the documentation around this stuff and making it easier for people to share commonly-used components.

[Alejandro Gómez]

Yeah. This is something that should be much improved with 0.8. Once that's out, it would be great to focus on improving the documentation around this stuff and making it easier for people to share commonly-used components.

In my experience with Ractive I worked with a team building a rich UI web application. This was meant for providing data management to large organizations.

In a normal app page, we needed to display a big data table, with around 250 cells (5 columns by 50 rows). Every cell was a living Ractive component, listening to DOM events. At the begining I thought this was fault of Ractive code, but at the end I learned that this is because manipulating the DOM can be very expensive in resources. But then I also realized that this was a very specific need from our business domain. Most of the webapps don't have such amount of components alive. So for those cases, Ractive components could be a very handy tool to make their development faster.

I'd like to join the movement that has already started discussing on what components they have to build and how they are going to build them.

[Tim Shannon]

 at the end I learned that this is because manipulating the DOM can be very expensive in resources.

Yep, I ran into this a lot as well.  Your app can get pretty sluggish if you're not too careful with Pushing items onto an array, or other array operations that iterative-ly update the DOM.

Best work in chunks or hide until everything is done loading, or whatever you need to do to minimize the number of DOM updates.

--
You received this message because you are subscribed to the Google Groups "Ractive.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ractive-js+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marty Nelson]

On gocardsmith.co we created some large boards that close to 1000 components. What I found was that slowness happens when you have unresolved references. After your page loads (you can do it on load, but it's a bit more tedious), do a search in the ractive source code for "attemptKeypathResolution":

  function attemptKeypathResolution() {
      var i, item, keypath, resolved;

      i = unresolved.length;

      // see if we can resolve any unresolved references
      while (i--) { // PUT YOUR BREAKPOINT HERE
          item = unresolved[i];

Then make a change that triggers an update. Check unresolved for length and a list of all unresolved keypaths. Most of those can be addressed by: 1) using restricted references in your templates, 2) set a data default in your component so it can resolve to root in that component.

We had page loads taking 30+ seconds that dropped to < 3 seconds.

0.8 handles unresolved completely differently. Rather than try to re-resolve unresolved on every runloop, it stores the unresolved in the model location(s) where it would resolve and checks when the candidate data changes.

[Dan Cătălin Burzo]

On https://app.moqups.com, we currently use components mostly for creating custom behavior for various input fields: inputs with an associated menu, inputs that are restricted to numbers (which then you can increment/decrement with arrow keys), combo boxes, etc. -- and for a rather complex color picker.

Here's how our `Ractive.components` looks:

ColorPicker, Droplist, ContextualMenu, Stencil, Throbber, Switch, SearchBox, TextInput, NumericInput, NumericInputWithExpressions, Slider, LinkDropdown, PolygonShape, WedgeShape, CalloutShape, StarShape, ArrowShape, SpecDistance, SpecColor

(We'd like to open-source these at some point, but have not had the time yet...)

--  Dan

[David Pesta]

@Dan - Wow, open sourcing those would be amazing! We're looking forward to it!

[Val K]

Hi guys! I'm new to Ractive and I'm impressed by it. But I wasted a couple of days to figure out  how  can I access to components. I found  that Ractive instance has Components property  (seen it  in browser console) and tried to use  it (and was very upset) until I figured out that what I need is findComponent and findAllComponent. There are thin documentation about it - I didn't find any clear instructions with example like ractive.findAllComponents('my-list-item')[2].get() - is it common practice to get/set component properties?.  What is the result of findAllComponents like if component A includes  component B, that includes list of components A?.  How can I go downstream on components  - something like   findComponent('A').findComponent('B').findAllComponents('A')[0]?

Thanks in advance

[Chris Reeves]

Component queries (findComponent/findAllCompenents) query the entire vdom hierarchy that is currently rendered. So if you want to find a deeply nested Foo component, `ractive.findComponent('Foo')` will walk down the vdom, including through child components, and find the first Foo. You can have the same component with different names in an instance's components map. The array returned from findAllComponents is in vdom order, meaning that a deeply nested A on the first component will be returned before the A directly after the first component in an instance.

I think it's generally not a good idea to tightly couple deeply nested components in your code, meaning that it's typical to have an instance only access its direct children. If some deeply nested access is needed, it's generally better to put an interface on it so that the instance doing the interaction still only has to deal with its direct children e.g. Foo has a Bar and Bar has a Baz that has a bat property - to get Baz.bat from Foo, it's better to have a getBat method on Bar that handles getting the bat and handing it back to the caller. That's an awful explanation and example, but hopefully it helps some :)

Thanks, Chris

--

You received this message because you are subscribed to the Google Groups "Ractive.js" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ractive-js+unsubscribe@googlegroups.com.

[Val K]

Thank you for your reply, Chris!

I agree that tight coupling could be source of problems, but first of all I want to clarify that findComponent/AllComponents  is only method to access component, because 'find' makes some mess  - why should I find if I exactly know? I just expected something like .Components['component_name'] or getComponent (like get() - get data).

Thanks, Chris

To unsubscribe from this group and stop receiving emails from it, send an email to ractive-js+...@googlegroups.com.