Proposal: Flesh out .extend ability for components

[imjoshdean]

Purpose

A feature sorely missed since the inception of CanJS's implementation of components is the ability to extend them. I'm not really sure why this never happened, but I think it's important that it does.

Allowing for the extensibility of components promotes the notion that people should be working in a component-heavy paradigm. Small, easily digestible, components should be encouraged that work as building blocks for bigger ones. A good example of this would be a simple form element:

Example: form-element component

A simple form element component might look like the following:

// src/components/form-element.js
import Component from 'can-component'

export default Component.extend({
  tag: 'form-element',
  viewModel: {
    key: 'string',
    value: 'string',
  },
  template: `
    <label>
      {{key}}
      <input {($value)}="value" />
    </label>
  `
});

What if we want to create another form-element, but one that would show some sort of validation error? Currently we would have one of two options:

1. Add additional functionality to the form-element component, thereby also adding to the complexity of the component
2. Duplicate this component, but with validation capabilities, and error rendering, but if our basic form-element template changes, we have to change this too.

Neither of these are ideal; however, if we could extend form-element, this could be a snap. The trick is figuring out how to handle extending each of the complicated properties: viewModel template, events, and helpers.

Implementation Ideas

events

Given that events is the source of a can-component's underlying control, this should work in the same way extending any can-control and subsequently any can-construct works, by initializing a new instance, and allowing it to inherit the parent control's prototype properties. If can-construct-super is utilized, the parent's functions should be accessible via this._super

helpers

Given the non-complex nature of these, the parent's helper functions should be made available via a shallow copy.

viewModel

Depending on whether a constructor function or an object instance is provided for the viewModel different things should happen.

Constructor function

If a constructor function is provided, this should override the parent component's view model.

Object instance

If an object instance is provided, it should attempt to extend the parent view model's constructor function with it's new properties.

template

While it might be implied that the rest of a component's properties could and should be extended, templates maybe moreso than the rest need to be extensible. The only way we can make truly extensible components is by allowing a child component access and use of it's parent's template. The way we would make that happen would be through a special tag: <super />

<super /> tag

This new tag, similar to <content/>, has one very explicit purpose: to take the parent component's template and render it at whatever level of scope it is rendered at in the template. It should not create any additional components whatsoever, and should be treated, more or less, as a suped-up subtemplate.

Basic Example

Using our first example of a form element where we start out with the following template:

<label>
  {{key}}
  <input {($value)}="value" />
</label>

Except now, we want to make a component that shows some error validation, perhaps with an unordered list. Because we are inheriting the parent component, we can do the following:

<ul>
{{#each errors}}
  <li>{{.}}</li>
{{/each}}
</ul>
<super />

This would ultimately render out the following:

<ul>
  <li>Email can't be blank</li>
</ul>
<label>
  Email
  <input />
</label>

Nested Example

Sometimes we want to inherit a component that might utilize a <content/> tag, we might want to use that DOM and shove our child component's DOM inside of it. Rather than treating <super/> as a self-closed tag, we should be able to achieve this by nested DOM elements inside <super></super>.

Let's take an example template for a person-greeting component. It might look like the following:

<div class="person">
  <h1>Hello, my name is {{name}}</h1>
  <content />
</div>

What if we wanted to take our person-greeting component and make it for businesses? We might want to include some information about a business or a company or a title. If we used a nested <super> tag, we could achieve this:

<super>
  <h2>I am a {{position}} at {{business}}
  <content />
</super>

Which would ultimately render out something like the following to our page:

<div class="person">
  <h1>Hello, my name is Josh</h1>
  <h2>I am a JavaScript developer at Bitovi</h2>
</div>

Adding the <content /> tag in our child template allows the new component to be utilized in the same manner as the parent one and provide light DOM to be rendered inside.

Summary

By adding these improvements, we promote the idea that we should be building small, easy-to-digest components. We also make it much more easy to simplify our codebases as well as making them less error prone by making DRYer. Using this feature should be very simple; we can easily create the originally desired error-form-element described at the beginning in the following manner:

// src/components/error-form-element.js
import FormElement from './form-element.js';

export default FormElement.extend({
  tag: 'error-form-element',
  viewMode: {
    errors: []
  },
  template: `
    <ul>
    {{#each errors}}
      <li>{{.}}</li>
    {{/each}}
    </ul>
    <super />
  `
});

[justinbmeyer]

Duplicate of #7. I'll close that one.

[justinbmeyer]

I'm confused about how <super></super> is supposed to work.

Does business-greeting's template look like:

<super>
  <h2>I am a {{position}} at {{business}}
  <content />
</super>

?

Why wouldn't it look like:

<h2>I am a {{position}} at {{business}}
<super />

?

[justinbmeyer]

Have you checked out slots #4 which would solve this with composition instead of inheritance? Generally speaking, inheritance isn't something we should push people towards. Though the use case of "extending a component easily" is something we should totally tackle. I like extending with composition instead of inheritance.

[justinbmeyer]

Can you give a full example of the extended FormElement. How would things get into errors, via outside bindings?

You could do much of this now like:

Component.extend({
  tag: 'error-form-element',
  ViewModel: {
    errors: Array
  },
  view: `
    <ul>
    {{#each errors}}
      <li>{{.}}</li>
    {{/each}}
    </ul>
    <form-element {key}="key" {value}="value"/>
  `
});

An alternative way:

stache.registerPartial("form-element", FormElement.view);

Component.extend({
  tag: 'error-form-element',
  ViewModel: FormElement.ViewModel.extend({
    errors: Array
  }),
  view: `
    <ul>
    {{#each errors}}
      <li>{{.}}</li>
    {{/each}}
    </ul>
    {{>form-element}}
  `
});

(alternatively, the FormElement constructor could have been part of the view model and its view could be rendered like {{>FormElement@view}} )

[matthewp]

Generally speaking, inheritance isn't something we should push people towards.

Inheritance is a perfectly valid way to inherit things in programming. There are strengths and weaknesses to inheritance just as there is strengths and weaknesses of composition. We shouldn't be dogmatic about anything and use what makes sense in any given situation.

[justinbmeyer]

@matthewp what is a strength of inheritance over composition? Other than being conceptually easier to understand, it is less powerful and tends to make less reusable and layered code. People also often use it incorrectly (see A typical violation here ). Also read Composition over inheritance. I feel like there's been a general consensus to avoid inheritance if good composition/mixins are available.

It's like imperative vs declarative programming. I think we absolutely should push people towards declarative code if both can be accomplished with similar effort.

Finally, there are limited resources. I'd rather spend time making things like slots work, or rest params canjs/can-stache-bindings#104 (another by @imjoshdean ).

[justinbmeyer]

To be clear, I'm not opposed to doing this. The previous issue was labeled enhancement and P3. I think that's still appropriate.

[matthewp]

Inheritance is built into the JavaScript language whereas composition is done with adhoc implementations that differ from each other. Using classes is nearly unavoidable in JavaScript; some APIs make it impossible to avoid using it; for example custom elements are built on inheritance. Here's an example use in can-custom-elements.

Composition has the disadvantage that it can often lead to too much abstraction that makes code hard to read. Here's an example of code I find difficult to read.

I feel like there's been a general consensus to avoid inheritance if good composition/mixins are available.

I disagree, JavaScript continues to get new inheritance features. That's strong evidence that there is not a "consensus" against classes.

[justinbmeyer]

JS's inheritance, imo, is a far cry from the inheritance patterns of traditional class based languages. It uses very different mechanics and it's only now making prototype extension an easy pattern for beginners to replicate. $.extend and now Object.assign are roughly the composition equivalents.

Regarding those APIS that require inheritance, afaik, there aren't deep inheritance trees in the wild. There are base types that get inherited one level deep. And anything else is probably better done via mixins. This was a huge problem with can.Model. While can-connect is harder to conceptualize, I think there's ample evidence that mixins have allowed an ecosystem to grow that was simply not possible with inheritance.

Is that example composition or functional programming? It reads like functional programming because it doesn't seem to be composing a type. It might be composing a behavior, but that's a different thing.

I've not seen composition lead to too much abstraction technically (I'm not sure that's actually possible). As I mentioned, it's only easier to conceptualize, just like imperative vs declarative programming.