What does it mean to have a Composition library

[karimayachi]

• It should use WebComponents in the same manner Knockout uses it's own components
• Does this mean exposing ((parent-)binding-)context to the WC?
• ?

[avickers]

I'm not quite sure what you mean by point 1.

I did include a .findParentContext() method for KD's base component class, but I wouldn't regard using it as idiomatic.

My view is that, as much as possible, attributes should be used. That improves interop with how normal/3rd party Web Components work.

To the extent that doesn't work, the idiomatic way to do it would be to use Buffer, KD's Single Source of Truth. Buffer is kind of like a shared View Model.

The problem with VMs/WCs directly acting upon their parent contexts is that, while it's fine for small projects, once you start having more complex projects/larger teams things can get brittle. You have to keep a mental map of all of the interdependencies or things will start breaking because it won't be immediately obvious while working inside of a parent context what descendants depend upon or expect to be able to act directly upon. (Therefore, it becomes necessary to write an over-abundance of unit tests.) Whereas by using either attribute bindings or a SSoT to drive state changes, it would be possible to immediately identify where interdependency exists from inside of either context.

Using attributes is the best option, when serialization is practical, because it makes the components built platform agnotistic. Components built that way don't even need to live inside the project. They can be published independently as normal web components and reused elsewhere, even inside of projects using other frameworks.

That's my 2 cents, at any rate.

[karimayachi]

I'm not quite sure what you mean by point 1.

I meant that all use cases for Knockout Components (KCs) should be covered by doing the same with native WCs.

The problem with VMs/WCs directly acting upon their parent contexts is that, while it's fine for small projects, once you start having more complex projects/larger teams things can get brittle. You have to keep a mental map of all of the interdependencies or things will start breaking because it won't be immediately obvious while working inside of a parent context what descendants depend upon or expect to be able to act directly upon.

I completely agree! But there is a situation where I use KCs that do need the binding-context and I wonder if that still is the case if it were replaced by WCs... That's when using slots, or light DOM.

Consider this example:

<divider-component>
   <div slot="left-column">
       <span data-bind="text: iComeFromTheBindingContext"></span>
   </div>
   <div slot="right-column">
       <span data-bind="text: iAlsoComeFromTheBindingContext"></span>
   </div>
</divider-component>

In KCs I inject the parent-context into the child-nodes of the component. Also with nested composition you probably run into similar situations?

[avickers]

I just tested that in my playground repo, and it works. I actually expected the binding to behave in terms of the parent context/light dom. What I was less sure of was if the child context mutation observer would also detect the binding and error after it was slotted, but it seems like the standards comittee thought through encapsulation pretty well.

I'll have to remember to test this boundary pretty thoroughly once Cypress (finally) ships shadowDOM support in the next few weeks.