Web component bug. Not sure how to explain it

There are some interesting behaviors with web components. I think i found a bug as I tried to update the tic tac toe example to imba 2.

See line 11 & 12. Remove < div to see expected behavior.

@somebee, please take a look at this when you get a chance.

Thanks.

I’ll get back to you about this tomorrow :slight_smile:

1 Like

There are two bugs here. One is that there already exists an app-root in the html, which is awakened immediately (without any data). But the bug you’re describing comes from the fact that custom tags inheriting from native tags are not working correctly with mount/unmount (as they are not really web components). We need to find a better way to deal with this. Expect it to work when 2.0 is released, but until then it is best to not inherit from native tags when possible :slight_smile:

1st Solution Sugestion [UPDATED]


Imba could support both custom components from v1 as well as web components, so the developer can navigate the advantages and disadvantages of each.

Custom Components

We could use PascalCase for custom components, which can inherit from native tags.

tag WebApp < div
  <self>

Web Components

And we could use kebab-case for web-components that do not inherit from native tags.

tag web-app
  <self>

Is there any greater performance to using web components?

@somebee
@scanf

2nd Solution Suggestion (WC & native tag inheritance)

1. Web Component (with native tag inheritance)

What if the code below

tag web-component < div

created a simple web-component wrap around a div, where <self> is the div itself.

In CSS, the div would then need to be accessed through a class

.web-component {}

as styling the web-component will not be applied to the div.

2. Web Component (no native tag inheritance)

When not inheriting from a native tag,

tag app-root

works as it does now in v2, and <self> refers to the web-component itself.

In css, the component would be accessed by the web-component name.

app-root {}

You could make it so that both types have a class assigned, but maybe it’s a good differentiation, as it would clarify in the css that they might have different behaviors.
@somebee
@scanf
I think I favor this solution more.
What do ya’ll think? What other solutions have you thought of?

This actually sounds good. I am not sure what kind of issues might arise
depending on how you mix and match them. There might be some hidden

edge cases, hmm…

1 Like