When in "Custom Elements Mode", Shadow Dom should be configurable and optional

felippe-regazio commented 1 year ago

This PR aims to solve:

Shadow DOM is optional and disabled by default in vanilla JavaScript Web Components. So, the same should be applied to Nano when in "Custom Elements Mode": https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM
{ delegatesFocus } is a ShadowDOM attachment option and should be part of shadow dom configuration and not a separated config. Also other options can be applied: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
Force a wrapper to the content of the component is only necessary when in shadow dom mode, when not, the component and the nano updates will be applied correctly without a forced wrapper (div)

Breaking Changes

This PR adds a breaking change to the "Shadow DOM Mode" feature

New Usage

On the current version, you can register a nano element as a web component with this API

defineAsCustomElements(
  CustomElementCounter, // nano component
  'custom-element-counter', // wc name
  [], // props
  // optional attach a shadow DOM mode to a custom element: open / closed
  // more info:
  // https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM
  // PROBLEM: if you omit this option the component will be created with a shadow dom anyway
  { mode: 'open' } // shadow dom mode
)

The new usage will add this behavior

// This will create a simple custom web component without shadow dom (as the spec)
// this is lighter and easier to work with (ignoring styling caveats that can be easily solved)

defineAsCustomElements(CustomElementCounter, 'custom-element-counter');

This will attach a shadow dom

// This will create a simple custom web component without shadow dom (as the spec)
// this is lighter and easier to work with (ignoring styling caveats that can be easily solved)

defineAsCustomElements(
  CustomElementCounter, 
  'custom-element-counter', 
  [], 
  { mode: 'open', ... /** add any other shadow option here, like an original wc **/ }
)

This behavior will drive the nano Custom Elements API to behave like a vanilla web component, making it more familiar and easier to configure.

TODO

If the PR gets approved, I must update the docs

yandeu commented 1 year ago

Thanks @felippe-regazio,

I personally never use defineAsCustomElements, so I have to read and inform myself a bit.

felippe-regazio commented 1 year ago

Ok, no prob. I believe this is intrinsically related to the other PR and the same discussion. In my opinion would be great to add @Shinyaigeek in the discussion, also.

Im excited to help to evolve the CustomElementsMode because I believe that could be a great start to write real "framework agnostic components" with a cool componentization API/micro-framework.

yandeu commented 1 year ago

Now that I have remove the data-wc-root and read some thing about this topic I finally see the difference.

Omitting the 4th argument in defineAsCustomElements will not crate a shadow root.

I think it is a great PR!

// https://github.com/nanojsx/nano/blob/master/test/nodejs/customElementsMode.test.tsx#L24
+ Expected: "<body><nano-test1></nano-test1></body>"
- Received: "<body><nano-test1><div>test</div></nano-test1></body>"

yandeu commented 1 year ago

I really like it 🤩, I think I will start building WebComponents as well.

felippe-regazio commented 1 year ago

_I really like it starstruck, I think I will start building WebComponents as well.

WCs are great! I will work on some testes, resend and then merge the PR :)

Shinyaigeek commented 1 year ago

Sorry for the late response. I really like this proposal!! I will look this PR ASAP( and also #129 )

Shinyaigeek commented 1 year ago

I saw the diffs in this PR. This PR causes a breaking change where the shadow dom is not encapsulated when the 4th args is not specified. I thought about the impact of this breaking change on users but

It should be almost impossible to break the shadow dom encapsulation by removing the shadow dom encapsulation.
Of course, if there is a logic that breaks when querySelector is not able to access it because it happens to be a shadow dom, but is able to access it after this is released, it will be broken…
- But it is very unlikely.
- Even if it happens, it should be easy to fix.
Of course, the way to opt out shadow dom should be provided

I feel that this is a reasonable breaking change!

nanojsx / nano