We just released v1! That means we can do what we’ve been eagerly awaiting: work on and ship new features!
We don’t have an official roadmap yet, and while I can’t speak for the core team as a whole, here’s a list of some of the things that I think will probably be on our post-v1 roadmap (in no particular order):
React 18
SSR/Edge rendering
Live queries (or something akin to GraphQL subscriptions, if not GraphQL subscriptions)
ESM compatibility
Distributing the CLI as it’s own binary
React state-management libraries
Adding a new “side” (CLI, Svelte, React Native, etc.)
Adding tRPC as an option
Better generators, component organization
Sharing code between sides
Focus more on performance
Continue investigating other GraphQL Clients (e.g. Relay)
Better debugging story
Ensuring the api and the web sides are decoupled
Making the framework more pluggable (e.g. hooking into the CLI)
Exploring Yarn 3 features (namely, pnp)
Revive the RedwoodJS VSCode extension
Improving the contributing workflow
Better yarn create-redwood app experience
Investigate compatibility with something like Nx, turborepo
Better yarn redwood console
Note that not all of these features would require a major release. It’s very likely that most of them could be shipped in a minor release.
But we want the community to drive priorities too. What would you all like to see?
Addition of a generator that matches your schema to use in your scenarios, so you don’t have to manually add all modifications to all scenarios each time.
Those would be 3 topics I’ve actually wanted to work on, the first one being maybe the most obvious to other users.
Also: Graphql Yoga enables file transfer, but our client doesn’t.
Any progress/discussion/plan over this feels important.
Great list though, I’d also be interested in schema stitching, have tried a couple of things and I think the graphql handler might require some serious tweaking for this.
Hey! My insignificant 2 cents: I would love to see Redwood support Electron.
As a solo developer, I want to focus on the task at hand, not juggling a million code bases. Redwood is a superb step towards my dreams. However, if it supported something like Electron, Redwood now goes from supporting web-apps to all-apps. This means that I can focus on creating the product without worrying about if I’ll need to recreate if for each platform as an app later down the road.
Are RedwoodRecords going to stay? They are experimental, I’m reluctant to further implement them if they don’t pass the “experimental stage” in v1, it would imply lack of support and possible drop.
Something really ambitious, but I would like to share it to find whether it is too ambitious: reversible generators. The tutorial is a good example for such tool as it presents many if not all rw generators.
I would really like to be able to step forwards and backwards through the process started by yarn create redwood-app. This ought to work even for apps that went beyond the point where tutorial app ends - as long as my app was strictly following the are prescribed by RW.
Ideally, a redwood app should maintain a special log that records all actions - and offer a step back it this step is reversible. I am not sufficiently experienced with databases, but I there some of them that can be reversed. Rather than limiting the app generation to CLI local app, this process generation should be similar to puppeteer.
If this messages make me remind you of Jules Verne, think how many of his visions materialized.
Also, improving CLI performance would be a major win in terms of DX.
Right now all commands seem to hang for a few seconds before spitting out the output. It feels unresponsive. A rewrite to a low level language like Rust would likely solve this issue, but maybe there’s a simpler solution?
Live queries (or something akin to GraphQL subscriptions, if not GraphQL subscriptions)
Better generators, component organization
React state-management libraries
Ensuring the api and the web sides are decoupled
State management is an interesting one and I have yet to found something that is easy and well organized as vuex in the react landscape. I found redux to be extremely complicated and react context is build on top of those design flaws I would say so no bueno!
Recoil I liked but I had little bit problem with setting it up correctly in redwood.js project all of my tests were failing because of some provider thing but apart from that it did work. It play really well with react particularly the “hooks concept”. However I didn’t really like the code organization it reminds of the Redwood Services. I’m the type of person that would most likely reach for RedwoodRecord instead.
Mobx is another on that I have played with it in the past in my previous job we used that. The problem is the different mental model that it comes with. It’s very class based like very much OOP style it might throw some developers off that are used to more function or hooks style of development.
Apollo client I have not tried but I don’t think redwood should use that either, in my opinion. I would not mind if the created their own state management solution. The did that with redwood router
Ensuring the api and the web sides are decoupled
For example if I have the django & graphql or rails & graphql can I still get the same integration and benefits on the client like code sharing and so forth? Maybe more guidance here I’m not sure.
Better generators, component organization
Component organization here is a bit messy I always remember rails generator having the easiest structure to follow when it came to CRUD
Sounds like you have something more to say about Redwood services? At scale I had to rethink about them, maybe there’s something here.
Great to know, it’s a way of contributing I’m looking forward to. Some cookbooks could be pretty good first examples of plugins actually - I’m eyeing at the File Upload, currently implementing it.
Additionally would like to see better error messages. A lot of times there are issues that pop up with really vague errors. Maybe that falls under * Better debugging story
I really like the idea of more sides. I think that it can really make redwood stand out against other frameworks in the space. I think that we should probably nail down patterns on things that are missing from the API side first like live queries and SSR before we expand though.
If we focus on some more server-related things it would be nice to figure out emails and async jobs things that all apps need at some point.
Last time I looked at state management libraries I really liked the look of Hookstate. But then I just did what I needed with React Context instead, and have been happy with that choice in multiple projects over the last few years.
For anyone interested in Recoil I’d suggest you also take a look at Jotai
