🎉 Tracking issue for v0.19.0 release 🎉

[mc1098]

This is a tracking issue for the upcoming v0.19.0 release 🎉

There are a number of things that I think should be completed before release and some others that would be nice to see included but shouldn't prevent the release. None of this is set in stone and I welcome everyone to comment below whether you think something should be added or removed from either list!

Blocking (in no particular order):

• Setting optional props with base expr fails without Some(...) #2034
• Tasks are not removed from Vec in file upload example #2035 (this issue exists in the master example too)
• VComp is not mounted #1946
• Improve documentation of the router #1852
• Integrate use_ref with NodeRef #1642
• Some events doesn't work since listener multiplexer update #2061
• Allow specifying worker script location as absolute or relative to current path #2056
• Example using function components #2072
• yew_router::attach_route_listener Event listener provides previuos route instead of current #2116
• AttrValue's PartialEq takes the enum variant into account #2161
• Yew router example main.rs component does not update html at all #2168
• Event propagation cancellation check happens too early? #2185

Notable but not blocking (in no particular order):

• Support Rc in html! attributes #1851
• Anymap dependency is unmaintained #1844
• yew_router should provide an ergonomic way to access the fragment from the URL #1858
• Rewrite router more #1860
• Factor out support for query_arg binding from rest of router changes #1892
• Bring the context method more inline with other Yew APIs by separating #1891
• Add ergonomic support for nested routers #1853
• Improve macro hygiene #1633
• Add the ability to add child nodes conditionally in html! #1609
• Replace uses of anyhow with error types #925
• A proposal to include the `spawn` keyword in `send_future` and friends #2048
• A proposal for a new type to describe component and agent references #2050

Issues that can be closed by new release

• Routing doesn't work #1986
• Cannot fetch with relative paths #1985
• Document Firefox WebSocket flakiness? #1045

Two of these issues are about services that are going to be removed, so can't be fixed, and one is a more general
critique of the router which has been re-written.

Misc

Some extra bits to do before the release:

• Review dependencies
• Review and list issues that are resolved by the new release (more of a note to self 💭)
• Confirm that each example is working correctly (the CI only checks if they compile) ( Tracking issue Tracking issue for testing examples before 0.19 release #2205 )
• Consider migration information and where it would live - yew.rs? as a discussion? ( PR Add migration guide for 0.19 #2210 )
• Update CHANGELOG ( Open PR generate 0.19 CHANGELOG.md #2199 )
• Add the new version and make it default in yew docs (No need to copy all files, just make it so that new version points to same things as "next") ( Open PR Final documentation touch ups & tag 0.19.0 #2220 )

Expect all sections to change - I will update it as we go :)

[ranile]

Can we pin this issue?

[siku2]

Can we pin this issue?

Oh, could've sworn I had already pressed the button 😅

[mc1098]

Should we also add an example that uses function components to the list?

I wonder whether it's useful to base this off an existing example so that users can compare the two
approaches side by side.

Edit: this has been added in blocking issue list as an example for function components had been mention by #1129

[voidpumpkin]

@mc1098 Could we add #2118 to this list as well? Getting current route will be impossible otherwise in yew@0.19.
(It solves bug #2116 )

[voidpumpkin]

#2125 Is a nice feature and just missing documentation. Would be nice to have it for yew 0.19, so will add it to the list. Let me know if this is not ok.

[ranile]

#2125 Is a nice feature and just missing documentation. Would be nice to have it for yew 0.19, so will add it to the list. Let me know if this is not ok.

Even if we can't release it alongside 0.19, we could always release yew-agent 0.2. Agents are a separate crate now

[voidpumpkin]

@hamza1311 oh that's right, thx
No reason to keep it in this list then

[voidpumpkin]

I moved still open issues to 0.19 milestone, so I think this can be closed.

[voidpumpkin]

Also leaving a comment here:
Moderators are working on setting up some automation for releases and 0.19 release is being held hostage because of that.

[ranile]

Re-opening this. The can be closed when 0.19 is released.

[mibes]

Does it make sense to reconsider this statement in the README as part of the 0.19 release?

Note: Yew is not (yet) production ready but is great for side projects and internal tools.

For example:

Note: Yew is not 1.0 yet, so expect API changes.

Having used the master branch now for a while, I wonder if yew v0.19 is truly not ready for production use, keeping the above caveat in mind.

[voidpumpkin]

Does it make sense to reconsider this statement in the README as part of the 0.19 release?

Note: Yew is not (yet) production ready but is great for side projects and internal tools.

For example:

Note: Yew is not 1.0 yet, so expect API changes.

Having used the master branch now for a while, I wonder if yew v0.19 is truly not ready for production use, keeping the above caveat in mind.

I would not reccomend yew in production, the api might change too mutch, to the point where you will be refactoring your app more than writing features.
I do agree that we are getting a lot closer to 1.0 and maybe even the next after 0.19 release might be the one.
But until then I believe the statement in the README is valid

[jbg]

The scary words "Yew is not (yet) production ready" make me think more of random crashes than API breakage. If you just mean that you don't promise API stability, then say that you don't promise API stability.

[mibes]

I agree with both your positions. I can see that you don't want people to be disappointed or frustrated by having to do major refactoring on API changes. However if you are open and transparent about this, it would be the user's decision if they want to take that work on, or not.

As @jbg pointed out, the current statement, does not do justice to all the work that went into yew up to this point and the level of quality it is currently at.

So maybe make the statement even more explicit:

Note: Yew is not 1.0 yet. Be prepared to do major refactoring due to breaking API changes.

[voidpumpkin]

I agree with both your positions. I can see that you don't want people to be disappointed or frustrated by having to do major refactoring on API changes. However if you are open and transparent about this, it would be the user's decision if they want to take that work on, or not.

As @jbg pointed out, the current statement, does not do justice to all the work that went into yew up to this point and the level of quality it is currently at.

So maybe make the statement even more explicit:

Note: Yew is not 1.0 yet. Be prepared to do major refactoring due to breaking API changes.

Could you make a PR?

[mibes]

Sure.

[mc1098]

Yew v0.19.3 has been released 🎉 so I'm going to close this now 🥳