Mitosis Context not implemented in every generator

[luislpv22]

I've realised that createContext and useContext features aren't implemented yet. Is there an ETC for these features?

Btw, this package is awesome, looks very promising to me.

Thanks!

[tomByrer]

https://github.com/ryansolid/solid/blob/master/documentation/context.md

[luislpv22]

I've tried before with this:

import { createContext } from '@jsx-lite/core';

export const MenuContext = createContext({ foo: 'bar' });

export default function MyComponent(props) {

  return (
    <MenuContext.Provider>
      {props.children}
    </MenuContext.Provider>
  )
}

But it outputs that:

JSON

{
  "@type": "@jsx-lite/component",
  "imports": [],
  "meta": {},
  "state": {},
  "children": [
    {
      "@type": "@jsx-lite/node",
      "meta": {},
      "properties": {},
      "bindings": {},
      "children": [
        {
          "@type": "@jsx-lite/node",
          "name": "div",
          "meta": {},
          "properties": {
            "_text": "\n      "
          },
          "bindings": {},
          "children": []
        },
        {
          "@type": "@jsx-lite/node",
          "name": "div",
          "meta": {},
          "properties": {},
          "bindings": {
            "_text": "props.children"
          },
          "children": []
        },
        {
          "@type": "@jsx-lite/node",
          "name": "div",
          "meta": {},
          "properties": {
            "_text": "\n    "
          },
          "bindings": {},
          "children": []
        }
      ]
    }
  ],
  "hooks": {},
  "name": "MyComponent"
}

REACT

export default function MyComponent(props) {
  return (
    <>
      <undefined>{props.children}</undefined>
    </>
  );
}

[steve8708]

@luislpv22 you're correct context is not yet implemented but on the todo list! will follow up here when we have updates on that

[tomByrer]

Any progress on this please? I was looking into translating some React into JSX-Lite, but seems useContext is all the rage these days ;)

[steve8708]

definitely still on the todo list - trying to carve off time soon to knock out this and a few other things!

[steve8708]

actively working on this over here https://github.com/BuilderIO/jsx-lite/pull/113

[CKGrafico]

useContext seems implemented but not documented, isn't it?

[PatrickJS]

yeah not documented because there were questions on what the angular/webcomponent version looks like

[PatrickJS]

to create the context for angular. I still need to work on here. https://github.com/BuilderIO/mitosis/issues/330 but to consume context works correctly. For what you're doing there might be some questions on how it would work with Angular and other frameworks if everything was in Mitosis

[kylecordes]

Idea for webcomponent: emit code that stores context on the DOM, and walks up the DOM to retrieve it.

[PatrickJS]

For webcomponent thats exactly how i wrote it and the context can be a Map instance

[CKGrafico]

Because to use a state management library that is agnostic to the framework is too much? Examples:

• https://github.com/pmndrs/zustand
• https://ngneat.github.io/elf/

[samijaber]

@CKGrafico There is absolutely nothing preventing someone from using a (framework-agnostic) library with their Mitosis components! That should work just fine 😄

[CKGrafico]

Sorry for the late response @samijaber I'm thinking into combine your useState with zustand seems the best option. I was also thinking into totally avoid your usestate to be sure that all the frameworks have state, for example using https://jotai.org/ but I hope is not going to be necessary.

Thanks for your work!

[CKGrafico]

BTW, is still imposible to use useState in angular right? https://mitosis.builder.io/?outputTab=IYOw5grgNsBOQ%3D%3D%3D&code=JYWwDg9gTgLgBAbzgVwM4FMDKMCGN0A0cEAdgLITInwC%2BcAZlBCHAEQACARssADYAm6KADpgEAPQhgMCKmCpWAbgBQy9AA9IsOIPo5kvePSoBjGGJJwyATwDCzSCXTUAFGCZhUASkTK4cE1JUeABtEhwQQjgMGAA5CPQAXTgAXhQMbDx0F1ZsdAA3dFYvFT9ickpXFx8UgD5ff38Y%2BMiXAHIARR4AR2R0NpKymkGyqHQYZChLFzL%2FAB5%2BYHza2ca54BIwZBhVxoDUVBSEBF29gIheaAAuNjH%2BVgJT%2FxoaJ7h8nF4%2Bo%2FDI17PGqRbAALHAkADm6COLgKzhgNXqzQSMMK1GEuCgkJgwg%2BX3QXn%2BZ3EKwBAAl0LxLgBCOAASQCYLgUCocA2cAASugcGYiAA1PpETAXYD8IjQOAAGWAvRFVNWc3Ei2WZUGNCAA%3D%3D

:(

[samijaber]

BTW, is still imposible to use useState in angular right?

@CKGrafico That is a separate bug that we should look into

[loganvolkers]

yeah not documented because there were questions on what the webcomponent version looks like

@PatrickJS - We did a big audit of web component / dom context implementations. There are a lot of different implementations, but all of them are subtly different, have different support for disconnect/connect due to moving dom nodes around, different event namespaces, and different support for arbitrary nesting.

I have tried to help move all of these dom context implementation towards a simple, centralized specification and standard. I haven't been as pro-active lately in trying to track down and centralize the approach.

See prior art and related projects in the readme: https://github.com/saasquatch/dom-context

[PatrickJS]

I think it makes sense to allow for anyone to toggle the DOM context standard you're proposing or at least allow for a way to use it. the problem with web components is that it's not a framework and you have to add everything a framework adds. Web components doesn't have any standards for most framework things so everyone has to make up their own.

The other thing about context is that you want types so we want to support strings but ultimately we want to support direct references to get the type info

I need to redo web components rendering and context which may effect how best solution for context. A lot of the web component context workarounds in the current implementation is due to having to work with the DOM directly rather than creating a copy then creating the view-ready version to insert or diff. I think we can go back to the simple version of rendering and context we have before in web components if we create copies rather than working with strings and current view.

[loganvolkers]

Also it looks like there is a community proposal Context Community Protocol by the W3C's Web Components Community Group developed by the Lit team since we published dom-context.