Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Framework Integrations other than React? #277

Open
XiNiHa opened this issue Nov 13, 2022 · 6 comments
Open

Framework Integrations other than React? #277

XiNiHa opened this issue Nov 13, 2022 · 6 comments

Comments

@XiNiHa
Copy link
Contributor

XiNiHa commented Nov 13, 2022

I'd like to use Stackflow with other frameworks than React, especially with SolidJS. While I'm somewhat interested in building the integration by myself, it looks not that easy to start with since the current integration code for React looks somewhat large to just read it without any docs, and the docs related to the architecture of the package are marked as in construction. Is it possible to get some support for SolidJS integration, or at least the docs to be prepared anytime soon?

@XiNiHa
Copy link
Contributor Author

XiNiHa commented Nov 13, 2022

I've spent some time trying to create SolidJS integration for Stackflow and realized that all the workspace settings and extensions are optimized for React. I have no idea how to manage extensions for different framework integrations available. Do you have any good ideas for doing this? Do you think that the plugins should be developed for each framework integration again and again?

@tonyfromundefined
Copy link
Member

I agree with what you pointed out! Soon we will be moving some plug-in interface implementations incubated in integration/react to "core". (The StackflowPlugin interface is now a common core interface, but the implementation is only in react integration.🥲 It not makes sense. 😂)

For this, several steps are required:

  • First, we will move the entire state management (including event dispatching) logic to the core module. (currently in react integration's CoreProvider)
  • Second, we will expose lifecycle hooks in our core state management logic. (Common plug-in interfaces can be inserted.)
  • Thirdly (if possible), we are going to use React.useSyncExternalStore() instead of useState() in React integration. (We will drop support for React 17 and lower later)

@XiNiHa
Copy link
Contributor Author

XiNiHa commented Nov 14, 2022

Sounds great! It'd be great for me to have further works linked with this issue, so I can get some notifications from it! 🙏

@tonyfromundefined
Copy link
Member

Currently, Karrot is undergoing migration, so stability and fulfilling existing requirements are of high priority. Perhaps an improvement schedule will be set at a later date, but I will let you know. Thanks for your contribution! 🤩

@gronxb
Copy link
Contributor

gronxb commented Nov 30, 2022

I had the same concern about the Vue integration. I want to get a notification, too!

@XiNiHa
Copy link
Contributor Author

XiNiHa commented Jun 30, 2024

I recently started my new attempt to make an integration for Solid. While mostly going well, I have these concerns/questions:

  • Would it make sense to provide a granular way to subscribe state changes in the core? Currently, it's forced to run reconcile to make the state update fine-grained. While this works for now, it'd be better in performance perspective if there's a finer-grained interface I can tap on to bail out of reconcilation.
  • Since UI and renderer plugins are tied to UI frameworks, the current approach I'm taking initial approach I took was to create duplicated packages for each of the first-party UI/renderer plugins (plugin-renderer-basic-solid, plugin-basic-ui-solid, ...) However, this resulted in lots of duplicated code, increasing maintenance costs. To minimize this, I have some options in mind. What would be the best way to handle the problem?
    • Extract only the VE styles from basic-ui as a separate package, and import them from each implementation
    • Extract all the styles and logics as a common interface, separated as a package, then hook them from each implementation
    • Same as above, but don't split the package and provide implementations for each framework as subpath exports. (maybe the React implementation should also be exported from . to avoid breakages... or should we just make a major version bump?) Make UI frameworks as optional peer dependencies (I went with this for now)

While I definitely want to upstream the changes, I'm open to maintain a separate fork if you're worried of maintenance cost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants