These are chat archives for skatejs/skatejs

13th
Apr 2017
Tauren Mills
@tauren
Apr 13 2017 06:47
@treshugart so does this mean I’d have to do this?
<u-tabs>
  <section attrs={{ title: "Tab 1”, icon: “google” }}>content panel 1</section>
</u-tabs>
Tauren Mills
@tauren
Apr 13 2017 06:55
I just tried that and it works. I guess I never fully understood this limitation. I don’t like the idea of different interfaces depending upon if I’m using my WC within a React app or not. I was hoping to publish a set of WC that can be used within apps built with vanillajs, jquery, backbone, ember, angular, react, etc. It won’t be a great user experience if the way they are used are different depending upon the app platform.
Is this really as good as it gets when using WC's within React? Is there some other solution? Would using them within Preact not have this problem?
Tauren Mills
@tauren
Apr 13 2017 07:23
I’m using 4.x. So are you saying that in 5.x the attribute value in the DOM won’t be the same as the value in the WC due to one-way binding? Would adding and removing tags by typing into the input not update the tags value in this: <sk-tags tags=‘[“apple”,”orange”]’></sk-tags>? (see https://hackernoon.com/building-a-custom-tag-input-with-skate-js-fbd4cdf744f for implementation). Is there an upgrade guide somewhere for 5.x?
Trey Shugart
@treshugart
Apr 13 2017 16:25

@tauren

I don’t like the idea of different interfaces depending upon if I’m using my WC within a React app or not.

This actually isn’t even an issue. I actually have no idea what you’re trying to do. This is 100% React’s problem; it has nothing to do with Skate or Val at all other than that Val enables you to tell React exactly what you want it to set

Your component’s API will never change in different contexts. The only issue here, is the framework / library you’re consuming them in might require you pass information to them differently. For example, things would just work for you in Preact. In React, to set props, you need Val.
Trey Shugart
@treshugart
Apr 13 2017 16:32

I’m using 4.x. So are you saying that in 5.x the attribute value in the DOM won’t be the same as the value in the WC due to one-way binding? Would adding and removing tags by typing into the input not update the tags value in this: <sk-tags tags=‘[“apple”,”orange”]’></sk-tags>? (see https://hackernoon.com/building-a-custom-tag-input-with-skate-js-fbd4cdf744f for implementation). Is there an upgrade guide somewhere for 5.x?

Exactly. You can still enable it (which I will get into after laying out the problems). There’s several problems with two-way binding of attributes:

  1. Peformance. Setting attributes is 3x slower than props, and in most cases it’s unnecessary. The only times you need it are when you need an attribute for styling.
  2. Many DOM props behave this way, such as value. One’s such as id do reflect, but this is inconsistent with others and Skate can’t tell what the user wants to do, so it takes the optimistic path here.
  3. Virtual DOM libraries may become out of sync if the component modifies itself.

One-way binding is on by default for built-ins, which is props.string, props.array, etc, but off by default just as before if you’re passing your own set of options that aren’t pre-defined as they are with those built-ins. You’ve always had to do { attribute: true }. The built-ins now just do { attribute: { source: true } }.

To enable two-way binding with built-ins, all you have to do is: myProp: { …prop.string, { attribute: true } }, and that’s it.

Tauren Mills
@tauren
Apr 13 2017 18:06
@treshugart thanks for the explaination. I do understand this is 100% react’s problem and that your val library is helping deal with the problem. What I’m trying to do is build a documentation/demonstration site that illustrates how to use a custom web component library. The users of these web components want to see how to use them, but some of them want to use them within React apps. This becomes problematic, since the documentation will need to show different markup for using in React than other frameworks.
I was mostly asking if you had ideas on another approach to solve the problem (possibly in a different way than Val takes) that would have consistent usage markup across libraries.
Trey Shugart
@treshugart
Apr 13 2017 18:09
I would just call out the problem with react and provide the solution for it.
It’s really the only problem here. Everything else you’d just set props. Preact works just fine, so no need to call much out there, other than maybe to ensure that custom element definitions are loaded prior to Preact stamping them out, in order to set props, otherwise they have to use Val, too.
Tauren Mills
@tauren
Apr 13 2017 18:11
ok, thanks.
Daniel Almaguer
@deini
Apr 13 2017 20:44
Q: Is there a way to dynamically load and register components on runtime?