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

Break the primary yew crate apart into discrete chunks #1670

Closed
1 of 3 tasks
jkelleyrtp opened this issue Dec 23, 2020 · 1 comment
Closed
1 of 3 tasks

Break the primary yew crate apart into discrete chunks #1670

jkelleyrtp opened this issue Dec 23, 2020 · 1 comment
Labels

Comments

@jkelleyrtp
Copy link
Contributor

jkelleyrtp commented Dec 23, 2020

As part of SSR, I've been wrenching on the main yew branch. However there are a bunch of extra bits that seem to bloat the primary crate. In my branch, I've done these things

  • Move the format module out into its own module (yew-format)
  • Move the agents into their own crate (yew-agents). Agents don't need to be built into the VDOM framework, and are further bloated when trying to target other platforms.
  • Move the VDOM into its own crate / leave it as yew-core
  • Make the scheduler a trait and force it to be implemented by the various backends. This can be specific to a backend
  • Move everything into a packages folder to tidy things up.
  • Move the services out completely. An update to websocket service should be isolated to a services module.

My dream is to strip down Yew as much as possible, and then support a wide array of backends. With an improved router, we have the unique opportunity to target every platform with very little hassle:

  • iOS apps as an alternative to React-Native or flutter
  • Android apps as an alternative to react-native or flutter
  • Desktop apps as an alternative to electron
  • Web apps as an alternative to the npm ecosystem
  • Web apps via SSR as an alternative to django
  • Hybrid apps as an alternative to live view

I think I understand the repo structure, codebase, and CI enough to help accelerate these changes and start bringing support to all the platforms listed above. The general thought process here is that "yew-core" should not depend on a backend, and instead be simply a lingua franca UI toolkit that different backends can render to their respective platform.

Questionnaire

  • I'm interested in implementing this myself but don't know where to start
  • I would like to add this feature
  • I don't have time to add this right now, but maybe later
@hamza1311
Copy link
Member

Closing since this has been done for the most part.

Move the VDOM into its own crate / leave it as yew-core

See #758

Make the scheduler a trait and force it to be implemented by the various backends. This can be specific to a backend

This doesn't seem like something that will happen soon. Feel free to create a new issue about this, explaining your yew-core proposal in detail.

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

No branches or pull requests

4 participants