Important explanation: I did not imply that my wishlist should be considered in the next release - it (wishlist) states only that it should be considered for the future.
Also:
Yes yes and yes 
Wow!
After digging deeper into RedwoodJS, I must say it is an awesome framework.
In order to make it really AAA you must prioritize:
Welcome @fenos !
There’s a team at work on this already, so it’s only a matter of time. Stay tuned! And if you have specific requirements/opinions, we’d love to hear about them to make sure we’ve got you covered.
welcome @zpeters! thanks for your git suggestion. There is already some prior art in this space that we might be able to leverage if we did want to go with this implementation route:
Ideally, it would be great to have template generator with the support for storing the templates created with it
@adriatic, @realStandal and I were just talking about making generators more composable so that instead of generating component, test, story all at once, you could choose just a subset of those. This idea lends itself really nicely to your template idea.
The reversible generators is something I have not given all that much thought into, but is a very cool idea imho.
I would really like to be able to step forwards and backwards through the process started by
yarn create redwood-app
Is this the primary use case you envision for it? I can see a definite value in terms of documenting steps to help someone’s learning.
Typically, when I have seen transactional databases that allow for rolling transactions back, it is to reconcile an error that got into the data. In theory, if the rw code generators are doing their job, no errors should come from them; so I see less value in being able to reverse them outside of a learning context. Super interested in hearing your thoughts.
@bitshift let me make some comments on your sentence
Is this the primary use case you envision for it? I can see a definite value in terms of documenting steps to help someone’s learning.
Help with learning is not the primary reason in my opinion - developing apps is more important. When I decided to participate in the last Tutorial QA, I was not a RW newbie, but wanted to check every written word (looking even for typos) as well as every JavaScript statement I wrote following the tutorial, trying to ensure that my just written copy is the same as Redwoods own finished copy. So, my task was a lot less difficult than to create a new copy - I followed the tutorial, after all.
Do not be surprised when I admit that in my adventure in recreating the tutorial, I made too many errors to admit that as well. In each such situation I felt a dire need to be able to “walk back” to just before I made the error. Alas, this wasn’t possible, so avoiding to use GitHub as my help, realizing that the code implementing support for real walk back would have to be a lot smarter than Github (example: I forgot to invoke a generator that creates a lot of changes, completely invisible to me), I would resort to start from scratch.
I am very interested in the idea of reversible generators and templates editing/modifying so, I may just start with better definition of these terms.
gotcha. If this is the desired behavior, I might recommend leveraging git / atomic commit convention. It could be interesting to tie in generators to git so that you can easily “walk back” a step.
SSR/Edge rendering and anything perf related for me. Thanks for the work team!
My 2 cents:
The git atomic commit convention would certainly help a lot if the application being built is a sequence of JavaScript code. The generators (used to create initial skeleton: yarn create redwood-app ./myapp) add a lot of Javascript code, (example yarn redwood generate page home /) at nearly any stage of my-app development, and our “code-watcher” would know nothing of it. In other words, any generator would have to reversible.
Consider the extreme case - a finished application that you would like to “disassemble” into its parts expecting that it finally takes a form of “script” which resembles a puppeteer driven process that can “reassemble” these parts, after you edit this puppeteer script and remove a step that caused the problem you want to rectify.
The consequence of such programming method would be that instead of claiming that we use JavaScript, we would say that we use puppeteer script, a much higher level of abstraction. Once you realize that Redwood offers a higher level of abstraction by using code generators just to help the developer not to have to implement all of the pedestrian code.
Yes, this does sound like a science fiction, but using the (then brand new “C compiler”) to generate the skeleton of Z80 assembly code, process I used to write OS firmware, many dismissed as science fiction approach.
It seems that I am responding to “Post-v10 feedback” wanted.
Oh, I forgot !!
Deploy to Gatsby !
I forget who mentioned that…
And Node 18
For a buddy of mine
I thought that was literally only for Gatsby sites. Can you actually deploy other things too?
well it turns out that he’s not really using Gatsby – he’s using dist folders and nginx and calling it gatsby apps – a little confusion there.
he admitted that if my app wanted to use any of the Gatsby features that I was out of luck…
File-based routing, ala NextJS . Maybe I’m alone in this since I haven’t seen it mentioned. But I found it really intuitive to work with.
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).
@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.
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;