Generating Components and Actions
I’m curious if it would be possible for wasp to automatically generate components and actions based on best practices?
11 Replies
Yes! That is actually one of the things we are looking into adding next. E.g. when you define entity Task, Wasp could automatically generate CRUD actions/queries for you (e.g. getTask, createTask, ...). Is that what you had in mind?
Exactly! Auto generating template crud operations. Would be amazing if that kept up if you update your entity definitions over time, that would be an added bonus.
And for components. Creating the component file with imports would be a small but helpful step, especially for folks that are new to react.
Do you mean creating files and components after you define them in wasp and type in import Fn ? So that it takes the path of the import and creates it in this path?
Yes that is what I had in mind. Or even if there is no path create a file in an appropriate location and update the wasp file although I get that might be sketchy.
Wohooo @RufusRed, you just became a Waspeteer level 1!
yep makes perfect sense - we could generate some default components for you to get started with quickly. that is definitely aligned with the auto crud story
Ok this is interesting, just to make sure I got it right since we will be talking about this in the following days for our roadmap and probably tackling it, so I want us to get it right. Here are two distinct things we have been considering:
1. Scaffolding -> we generate some JS files for you when you are creating new page/action/query. Once we generate these files, they become your code that you mantain, this is just to get you started a bit more easily.
2. Auto-CRUD -> we generate actual React components for entities, for Create/Read/Update/Delete that you can plug in directly in your code and customize them a bit. So you don't have to write your own code. These get updated together with entities, and you can't edit them directly, you just use them, they are in the background generated by Wasp based on entities.
I think you were referring more to the #1 here @RufusRed ? But Maybe #2 is also interesting?
How exactly would you like #1 to work? Do you imagine you first define something in .wasp file and then we genreate js file for you? What if there already exists such JS file?
These are things I’ve considered and there are pros and cons. Let’s talk actions first and then components. For actions I think creating crud methods with specific names when an entity is added to a wasp file and first saved. This could create the file if it is not there. I think these methods could even be updated if attributes are added/removed from the entity in the future. People can still add other methods for joining/searching/use-case optimization. The challenge here is that someone might want to extend the base crud, in most cases this could be done with a different named method that is a wrapper. However if a user wants some of the crud methods to not be regenerated at all or they want to wrap the crud methods but not expose the generated methods. My take on this is if they could mark the crud methods as private and updates would honor that it will give them full control other than not being able to reuse the method names. And support continuous updates.
For Components I suspect it’s a one shot. You generate when the wasp file is saved only if the component doesn’t already exist. Ideally the templates used to generate these components would be designed to be updated easily the developer using wasp to build an application.
Wohooo @RufusRed, you just became a Waspeteer level 3!
I assume there is some sort of tree shaking so if this generated methods and components are not used they will not get added to the final built output?
@martinsos ^^
Thanks @RufusRed this helps! We have just been discussing this internally today and will probably go with something similar to the direction you described. As for tree shaking -> we have it to some degree, but we will make it 100% for Wasp 1.0, so yeah it shouldn't be a problem if some stuff is not used.