look into building tests for web components everywhere

[doriansmiley]

Fork here: https://github.com/webcomponents/custom-elements-everywhere. Create a test module for Lotus components.

• [ ] Find a way to dispatch events on the native element. Currently, we need to perform element.component.addEventListener. I don't think this is good. We should be able to propagate custom events on the custom element. This is going to require the dispatch to be performed on this.shadowRoot. To do this we likely need to pass a function reference to the component instance in the class wrapper. When a component wants to dispatch it can call the function ref passing the event. I don't want to pass the shadowRoot ref. Another option would just be adding an event listener for a generic forwarding event.
• [x] Custom elements anywhere require we support declarative and imperative events as well. IE events as attributes and events assigned with addEventListner. I'm not too into supporting the declarative handlers because it either requires eval, or I have to implement a babel plugin to transpile to the code. It's worth looking into it, but I will stick with imperative style and add plugin support for a future release. Sticking with imperative only for now.
• [x] Look into providing component data as properties. Currently, you have to call render(state). A better system would be: <lotus-custom-element {...state}/>. But if this requires a compiler to transform the DOMN fuck it. Use render. There is no easy way and it's not the best practice according to Google.
• [ ] Reflect attributes and properties for simple property values that do not change frequently. Read the article here to understand how to do that. Official docs on the attribute lifecycle callbacks are here.
• [ ] Look into using the element.dataset property to access the data-* attributes. Good article here from MDN. Look into switching to element.dataset, but it's not required.

"Properties are available on a DOM node when being manipulated by JavaScript. Attributes should only be used for scalar values like strings, numbers, and boolean values"

[ghost]

I made a fork of this.

[doriansmiley]

What I'm seeing is that anyone who supports the syntax sugar that web components anywhere wants you to implement is using a templating engine to transpile the code. At least a few are using React's JSX plugin for babel. This leads to larger bundle sizes for the emitted code. I do like a few use cases though which are:

1. Desctrucring object properties to HTML attributes
2. Declarative event handlers
3. Interpolation of random expressions in HTML attributes and children using {}.

If it were possible to create our own Babel plugins, that would be cool maybe. But syntax sugar can be addictive, and the entire point of this framework is to get closer to the DOM.

[doriansmiley]

I created a forked copy of the repo and create libraries/lotus. I started coding out the component and test under src. I left off on ComponentWithChildrenRerender. Once all the components are coded out code out the basic test. Then move onto advanced tests.

[doriansmiley]

Four of the basic tests are passing. This is a great setup for using TypeScript with Karma. Open another ticket to port our testing over to this setup. I updated all npm libs to the latest as well. This would be a good medium article. I would update the boiler plate ts generator with this as well.

[doriansmiley]

Pull request opened: https://github.com/webcomponents/custom-elements-everywhere/pull/1000

[doriansmiley]

I'm going to close this issue as I don't think the project is still active. I can always move people over to my fork if the maintainer does not respond.