Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use nested components instead of simple html. #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

SlexAxton
Copy link

In our app, we'd love to double down a little more on using components to wrap simple components. They rarely do a ton. Lots of times it's just sugar for adding various classnames:

{{#stripe-col grid="12,6"}}
  {{#stripe-content-box title="Foo Bar" size="large"}}
    This is my content.
  {{/stripe-content-box}}
{{/stripe-col}}

Which comes out with relatively simple, and not even necessarily needing-to-be-bound html wrappers:

<div class="stripe-col-xs-12 stripe-col-md-6">
  <div class="stripe-content-box stripe-content-box--large>
    <h1 class="stripe-content-box-title">Foo Bar</h1>
    <p class="stripe-content-box-content">
      This is my content.
    </p>
  </div>
</div>

This is a nice way to abstract the less pretty parts of css component frameworks and grid systems as well as a really cool way to abstract your desired markup for certain repeated components so you can make a single update to the component markup and have all instances upgrade at once (imagine the bootstrap 2 to 3 upgrade).

All that to say, I really like the idea of using components everywhere.

The problem we run into is that nested components take so long to initialize that it becomes by far the most expensive part of our render time. So what we did was use some of the private htmlbars APIs to create block helpers that don't require a view creation. We just make dom elements by hand and inject text nodes. It's unbound, but that's usually fine for a lot of these less-complex ones.

The problem with those were that the APIs were private, and thus broke during every upgrade.

So the reason I'm submitting all this here, is that I think as part of ember's speed goals, having a bunch of components in a list shouldn't be a big perf hit. It seems like Glimmer will likely clean up most update costs to components, but my gut says that the initialization cost won't likely change much. I'd also be cool with some sort of 'less-features-mode' that you could put 'wrapper components' into.


Notes about this repo:

  • Some things are silly to be nested as they are, but it's an overly simple app. I don't think getting to ~4 or 5 layers of looped nesting is too hard in a real app
  • classNameBindings doesn't appear to work anymore. Could be me being dumb, or an API switch that I'm unaware of. I added some spots that use it, but currently they just evaluate to false, no matter what.
  • I don't think the current set of goals should be changed or anything. I just think that the next speed goal should probably include massive amounts of view creations. (And I understand people are already looking into this, I just wanted to maybe help with some test cases).

…mplex and nested application rendering situation.
@wycats
Copy link
Owner

wycats commented Jun 12, 2015

@SlexAxton that's pretty in line with what our next goals are, and this is a pretty good alt-benchmark to use for the next phase. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants