Roadmap
silvenon opened this issue Β· 18 comments
We would like to take this library to the next level, so it fits more nicely into modern React code. For usage in function components, react-transition-group's component API is clearly unnecessary, so we would like to eventually provide a hooks API as well.
First we would like to refactor the test suite with as many use cases for react-transition-group as we can think of, to avoid surprises in the future. Afterwards we would like to simultaneously work on building the hook API and fixing an issue with stale nodes (#623, #469). The stale nodes fix will probably be breaking, so we'll work on hooks in parallel to see if we need to make any more breaking changes to accommodate the hooks API.
This is also an opportunity to go through the rest of the issues to see if there are some echoing concerns that we can address in the following releases. π€
π
Hi, Matija!
I really like the library!) It helped me create such complex animation, which you can watch on my LinkedIn post
Πnd with all its simplicity and performance, I think it deserves more attention than it currently has (correct me if I'm wrong).
When I discovered RTG almost a year ago, it was difficult at first to understand, how can I create animations that I needed at the time. I think that was because of the lack of examples and not so clear explanations of core components. And the landing page looks really simple.
I think I have an idea on how to increase the popularity of the library and speed up it's learning by new users.
It has a couple of action points:
- Sell the library to a new user:
- Update landing page design, make it more professional-looking
- Create a logo (some examples from me below, but it's just a couple of minutes of work, nothing serious)
- Add a simple description of what the library does, when to use it, and in combination with which libraries are best
- Add comparison with other animation libraries by bundle size, performance, API, etc.
Logo examples
- Add many examples from "hello-world" level to advanced level.
- Add a "library" of predefined animation effects. It'll be user-friendly not to force users to create their own animations, but instead to provide several predefined animations.
I can help with all the points above.
What do you think?
I totally agree that this library that is seen as official deserves far more! Every time someone posted an issue where they misunderstood how to use the library, I committed a change to the docs in hopes to eventually make it clear enough, but apparently it needs something different.
Update landing page design, make it more professional-looking
Sure, I'm open to suggestions!
Create a logo (some examples from me below, but it's just a couple of minutes of work, nothing serious)
I like the one on the bottom left the most. π Looking forward to seeing the entire design.
Add a simple description of what the library does, when to use it, and in combination with which libraries are best
Yep, it's a bit hard to pin down, but I think the most common use case is animating presence of an element in the DOM. I'm very much open to suggestions.
Add comparison with other animation libraries by bundle size, performance, API, etc.
I'm not sure about comparison because other libraries offer more functionality, I see this library as the minimal React way to make the reflow hack, I'm not sure if there are other libraries doing only that. But bundle size couldn't hurt. π
Add many examples from "hello-world" level to advanced level.
Sure, the more examples the merrier!
Add a "library" of predefined animation effects. It'll be user-friendly not to force users to create their own animations, but instead to provide several predefined animations.
Can't they do that from examples? (The previous point.) Please explain further.
In any case, thanks for wanting to help, it's much appreciated, I'll be happy to review your code.
Is this also an opportunity to extend and improvee some functionality?
-
Add
modestoTransitionGroup
The SwitchTransitionmodesprop is really cool and I hope we can implement it inTransitionGroupas well.
Main idea is to be able to use modes while the child decides what kind of animation it should be using. -
Consistent API
Otherwise letSwitchTransitionwork likeTransitionGroupwhere the child is responsible of the animation.
This ensures that we have consistent API where if we use a wrapper transition (likeTransitionGroup), then the child components should be responsible for its own transitions.
Otherwise let
SwitchTransitionwork likeTransitionGroupwhere the child is responsible of the animation.
This ensures that we have consistent API where if we use a wrapper transition (likeTransitionGroup), then the child components should be responsible for its own transitions.
Isn't this already the case considering that SwitchTransition only takes mode and children?
I wish it does, but I got an error when used with 2 children.
@silvenon @jquense Is anyone maintaining this repo? I wondered it because the last commit not by dependabot is Jun 4 2020.
https://github.com/reactjs/react-transition-group/commits/master
Not for a long time, as you correctly noticed. I had plans, as described in this issue, but I lost my drive. If you're looking for a quick replacement, it looks like @headlessui/react is a good choice.
I also don't have much time for this. tbh I'm pretty disenfranchised with the idea of a good general purpose animation component like RTG or at least with me being a good person to do it. Most of these hooks or affordances really need to be built into React itself, like Vue and Svelte both have. The other viable alternative is pure JS driven libraries like framer motion, which are a big commitment but work great. I've found that in most cases with one off or simple CSS transitions it's just better to do it manually with a ref and some imperative code.
@silvenon @jquense
Thank you for your response!
I agree with you that there are now many options to implement animations in React ecosystems and web-standard ways.
But RTG is still being used in many libraries, so I think it would be nice if this is kept maintained.
Actually, I hope that RTG provides hooks API rather than components, but I think it's more important to fix bugs and update dependencies for ecosystems.
I might not be able to have much time on it, but if anyone won't work on it, I'd like to take over RTG.
Yep, this maintenance fadeout is the worst for such a popular library. I thought I was eventually going to deliver on my promise, but I should have realized that my focus has changed. As far as I'm concerned, please take over. π
happy to hand it off, RTG is heavily depended on and it's much better if it keeps being maintained.
@silvenon I'm working on the Fluent UI library, and we're looking into animations in our library. I also agree that the library could do with modernization especially on a hook based approach for animations. Would you be interested in working together on this?
What could the hook API give you that's more convenient for your goal? Did you try Transition from Headless UI? It's been meeting all of my needs and it's maintained by Tailwind Labs, who have resources for continued maintenance.
hi @silvenon, any thoughts around making nodeRef a required field instead of being optional?
Would probably be a good idea as part of v5.
Do we have a plan or active maintaince right now. It's absolutely ok if the answer is "no", I'm not exactly involved either. Mostly I just want to know if it'd be ok to PR a few ideas that change the API significantly.
I've written components and hooks to with RTG as the basis few times now and think I finally have some idea what a modern API might be useful. One that has hooks, and can handle web animations as well as declarative css transforms in a simpler fashion (with influence from framer motion)
I'd be into reviewing these PRs and talking about these ideas. But I wouldn't have the capacity to maintain.