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

Add ROADMAP.md #587

Closed
kellytk opened this issue Aug 13, 2019 · 2 comments
Closed

Add ROADMAP.md #587

kellytk opened this issue Aug 13, 2019 · 2 comments
Assignees

Comments

@kellytk
Copy link
Contributor

kellytk commented Aug 13, 2019

Description

I'm submitting a ...

  • feature request

A roadmap is a document summarizing the high-level direction of a project and enumerating its milestones. Roadmaps are useful to current users and prospective users alike.

As Yew matures, and a 1.0 release begins to come slowly into view, I think it would be a good addition.

@jstarry jstarry pinned this issue Sep 27, 2019
@jstarry jstarry self-assigned this Sep 27, 2019
@hgzimmerman
Copy link
Member

hgzimmerman commented Sep 27, 2019

Yew 1.0

Ergonomics/Usability:

  • Some CSS in Rust functionality: Styling Brainstorming #533
  • I'm in favor of waiting until expression proc macros stabilize so we can move away from proc-macro-hack to lift the limit on number of nested html! invocations. That may take some time though.
  • VDom access: Add support for setting refs on elements for DOM reference #665
  • I want to see pure components make their way into the ecosystem in some form.
  • I'm finding that having the returned Html<_> require a type parameter relating to the component it's callbacks have messages for gets in the way of writing concise generic components that can contain arbitrary content, especially nested components. Sadly, I don't have any real suggestions on how to remove this type parameter and allow simplification of the message/callback system.

Performance:

Documentation:

  • Getting started guide.
  • Internal implementation details, opinionated guidance to achieve best performance in apps.
  • Best practices for readability.
  • Global State management strategies.
  • Other misc patterns

Punting for Yew 2.0+

These would be breaking changes to a 1.0 release, and I am of the opinion that they could wait until 2.0.

  • callbacks vs futures: Consider handling async service effects through futures #364
    • Edit: I looked a little closer at that PR, and it seems like significant progress is being made there. I don't think this feature is required for 1.0, but if it gets finished before then, then I'm all for it.
    • Edit again: Delaying support for futures would be done on the basis that a callback model is good enough. I've done a 180 on this topic and now think that callbacks aren't good enough. Having to involve a component or agent's update loop makes code reuse rather hard, while there are many places where futures that can be composed together would be significantly more ergonomic, performant and readable.
  • I don't think we should abandon the virtual dom as it is right now. I don't know how hard it will be to adapt Yew to use an alternative VDom implementation. Use of Dodrio virtual DOM #482
    • There might be performance benefits to doing this that make it worthwhile for a 2.0 breakage.

Orthogonal to 1.0

Toss up

  • I would really rather not wait until 2.0 for a transition to web_sys from stdweb (if that's a thing that is going to happen). But it seems like a huge thing to change and would consume a bunch of resources to implement it. https://rustwasm.github.io/wasm-bindgen/api/web_sys/
    • I'm just scared that a breakage this large could break most existing libraries reliant on yew, so ripping the band-aid off sooner rather than later would be a be a good choice if this is going to happen.

@jstarry
Copy link
Member

jstarry commented Nov 28, 2019

Thanks @hgzimmerman we've made a lot of progress on the things you've listed here! I've written up a roadmap doc here: https://yew.rs/docs/roadmap let's work together to flush that out 👍

@jstarry jstarry closed this as completed Nov 28, 2019
@jstarry jstarry unpinned this issue Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants