We intentionally have not done this. But I’d be very interested to know what you like about it. Any examples you can share?
@thedavid I liked seeing my URL hierarchy at a glance in the sidebar of VSCode (ie as the file system hierarchy). That said, I realize there’s a bunch of other info in Routes.js that you’d need a way to express if you had file system routing. I think Nextjs left that as an exercise to the reader (which isn’t great).
1 Like
@nb90210 there’s some early code in the Redwood internal package that can help describe a Redwood app as a graph — and one of the outputs was a proof of concept of a VSCode IDE extension that could enumerate and display Redwood routes, cells, services and more in a tree view. And you could interact with them.
We can achieve that end state — seeing a list of routes — that way.
The IDE extension is definitely a v2 item.
3 Likes
FWIW - I’ll throw pullstate into the State competitors tourney. But as much as I hate to say it – Redux has TimeMachine. If I had a generator for Redux I might be convinced… I wonder if we could do something with a Prisma table – name a table and the generator would create all the Redux boilerplate as if that was your state definition?? Or specify a .json file, for that matter… I’d stay out of the generated code just to be able to re-generate it like a migration? (which is why I thought of Prisma… But maybe there’s code to do migrations on a .json structure?) – sorry, late night thoughts…
I would like the Docs to make a bigger deal about Upgrading the Framework
I can’t think of one Framework I’ve ever used that has dedicated resources to such a trying process
I think it deserves a full section in the Docs – talking about best practice (update Node, deps, or RW first), which then points to the tools involved
Thanks!
Al;
1 Like
Related question from the About the Get Help and Help Others category: Correct way to reverse setup CLI command - #2 by dthyresson
This thread seems getting longer than I expected - meaning that my “fictitious” reversible application generation is more realistic than I expected (based on few people’s feedback). I have two points of encouragement
-
Eons ago, I was interviewed at Microsoft, and in that process I had a couple hours long session with Anders Hejlsberg. That was before typescript, so we discussed debugging innovations - and proposed the idea of the reversible debugger. Such ideal tool would support the notion of walking back from the crash, so one would find the reason for crash a lot faster than using the “bisection” method we all use today. To my surprise, (I thought that such idea was preposterous) he asked if I would consider leading that project.
-
While working on Aurelia open source project (I was a bit younger and had more energy) I actually initiated a project named Visual CLI (app playing the role of command line CLI) and with the team of 5-6 collaborators brought it pretty close to a “reversible CLI”.
Since this discussion is framed with Post-v1 Roadmap feedback, and because RWJS is more advanced than most, I hope that I am not stirring a storm.
@adriatic – I loved Aurelia for 8? years !! I got onboard while it was pre-release and left Angular happily behind!! I combined it with AdonisJS (a very well put together NodeJS version of Laravel) for the backend
@ajoslin103 Aurelia is still the most elegant and best designed framework. It did not reach the popularity it deserves for two reasons:
- No leader comparable to @mojombo (combining the creativity and resourcefulness)
- The core team is not even close to demonstrate the needed togetherness and respect for contributors.
The framework seems still alive, so that is good news
Ref: Cannot find module 'types/graphql' or its corresponding type declarations
I would like to be able to generate services and sdl – without a database model. It’s fine with me if they are empty as a desert… I want all the files…
2 Likes
I just ran into this problem – I needed to destroy scaffolding
@adriatic – I too had more energy in the past, but I would try to help
I’m not sure how to do it – why do you think to puppeteer script ?
I’m thinking more like down/up migrations – where we generate the entry and then execute the up side
AdonisJS had a nice cmdLine UI for migrations – Schema migrations
Dream: Angular has something they introduced recently - I can’t find reference right now - a code mod tool (I wish they did call it code mods) which understands angular conventions and can write & modify Angular code. I don’t know exactly what we use for codeMods – but I don’t think it knows React & NodeJS like this Angular thing – Ah! Angular Schematics – don’t know why they hide it… Maybe I need new glasses…
Anyway, back to dreaming… If we could AST sequences we’d be able to apply a scaffold when a sdl had already been generated – something we can’t do now without a --force on the scaffold
@ajoslin103 - As I am getting older it feels that I have more and more projects I would love to do. I am also happy to discover how you resonate to my dream about “reversible generator”. Staying in the boundaries of the theme of this conversation (Post-v1 Roadmap), I am very happy to see you mention puppeteer - tool already on my palette (read: the redwood testing and debugging tutorial:
So, using the analogy with a text editor (that i wrote long time ago), where the editor kept the log of all user’s keystrokes as well as the generated sequences sent to the screen. I made such log “playable” by the editor, so anyone who managed crash the editor, could send me this log instead of the bug report, I can envision an adjacent log generator tool running in the background doing a similar set of tricks. I can see a million “how could this work in God’s name???” questions, so if such idea ever takes root, I will provide a million answer
1 Like
He, I’d not have mentioned puppeteer unless you did 
Puppeteer makes sense
What do you think about an up/down migration history?
Super high on my list is how we deal with post-generator changes
1 Like
Just wanted to also +1 custom sides, as I feel like that would be a killer feature for Redwood as a framework. I know this is a “framework for startups”, but like Rails I can see its potential as a generally good full-stack JS framework for small to medium-sized businesses. As someone who has implemented Apollo Server and a GraphQL API directly (using TypeScript and GraphQL Code Generator, no less!), I can definitively say that it is a huge amount of code to maintain when all you really want to do is ship value for your users. Today’s landscape is a world of one graph powering multiple applications, and being able to develop them all side-by-side is hugely beneficial, you just need to do the work to get them all in a monorepo. Redwood, on the other hand, has figured all that out for you, so that’s why it’s wonderful.
On top of custom sides, and much like other users in this thread, I would also love to see some kind of Playwright integration. There’s a bit of configuration you have to do to Jest and Playwright in order for them to not try and run each others tests. Personally, I like to use .spec.ts for Playwright tests and .test.ts(x) for Jest tests, so I configure testMatch and co-locate my e2e tests with my pages. Not sure if this is desirable by all but I found it to be very comfortable when developing pages and integration tests simultaneously.
One of Redwood’s downsides is that it doesn’t have any way to rebuild statically generated pages, and its prerender option on routes leaves a lot to be desired (though I really do love the “dry run” option!). Unlike NextJS and similar frameworks, Redwood has a major advantage here: it encourages usage of Apollo for all data fetching. This means page prerendering can be very elegant:
import { useQuery } from '@apollo/client'
import LatestHeadlines from 'src/components/LatestHeadlines/LatestHeadlines'
import UpcomingEvents from 'src/components/UpcomingEvents/UpcomingEvents'
const HomePageQuery = gql`
query HomePage {
articles {
slug
title
}
events {
id
name
}
`
export const prerender = async ({ apollo }) => {
await apollo.query({ query: HomePageQuery })
}
const HomePage = () => {
const { data, error, loading } = useQuery(HomePageQuery)
return (
<>
<LatestHeadlines articles={data.articles} />
<UpcomingEvents events={data.events} />
</>
)
}
export default HomePage
Apollo already has functionality for hydrating the client with server-side data, so Redwood could call prerender() and then pass the data onto the client. This has been really helpful with our NextJS app’s performance and I think Redwood could not only change the game by doing it, but it would also be a lot easier to think about in Redwood’s world since Apollo pretty much already handles it for you.
2 Likes
Recently I got an email from a Novu core team member asking whether RWJS has interest in using their infrastructure. As I know that Tom is one of their seed investors I do not worry about missing their product - so I am just mentioning it in the context of this discussion.
1 Like
Re: * Better generators, component organization
Definitely something that would help scaling the code of a redwood app, I made an issue here:
I am also thinking of different types of components:
- Reusable components that must have stories (and must not use context hooks, or graphql queries?)
- Page components, single use, linked to a particular page (could be a folder inside the page component?)
This is subject to change, as I get deeper into using RedwoodJS and gain more experience with it. But after having worked with it for a few months, here are my priorities:
- React 18
- Chakra-UI 2
- Organize everything related to deployment into ‘environments’ – this should include NODE_ENV setting, as well as all DB related configuration (don’t separate datasource db url from ‘provider’), separate out settings currently dependent on NODE_ENV === ‘development’ (e.g., the GraphQL playground), migrations (since they’re db provider specific), keys related to deployment (e.g., AWS keys), ensure isolated use of keys (e.g., ensure you don’t pick up AWS keys from the shell environment) and I’m sure more.
- yarn rw cli should include ability to invoke all serverless framework commands. Currently the docs say to use
yarn serverless remove…to remove a deployment, but this will almost certainly use different AWS keys, since it won’t bring in the rw .env
1 Like
Hey all!
Would like to thanks everyone who are involved in this amazing framework, I’m clearly that kind of dev who is afraid to make the wrong choice of lib and a full featured FW like yours make me way more comfy!
After playing a bit with it, I would love to see those new features coming:
-
SSR/ISR is a big miss for me ATM
-
Sides, being able to use Svelte or RN with the same level of integration than React would likely make me use this FW everyday of the year! Being able to share code between sides is the natural next feature in that case
-
Vite/Vitest
Thanks again for your amazing work!
2 Likes
Thanks @johann-taberlet …
- SSR/ISR - yes, teams already starting to think up solutions
- We had interest from Svelte. I need to follow up with them.
- @Danny has done some experimenting here.
1 Like
+1 Electron support