Closed doriansmiley closed 3 years ago
I made a fork of this.
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:
{}
.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.
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.
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.
Pull request opened: https://github.com/webcomponents/custom-elements-everywhere/pull/1000
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.
Fork here: https://github.com/webcomponents/custom-elements-everywhere. Create a test module for Lotus components.
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 onthis.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 theshadowRoot
ref. Another option would just be adding an event listener for a generic forwarding event.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.render(state)
. A better system would be:<lotus-custom-element {...state}/>
. But if this requires a compiler to transform the DOMN fuck it. Userender
. There is no easy way and it's not the best practice according to Google.element.dataset
property to access thedata-*
attributes. Good article here from MDN. Look into switching toelement.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"