Custom DataClass generation

[micimize]

I'm interested in making a custom data class generator, but would like to avoid forking. My current thinking is to PR:

• A change to factor out generators for various dataclass methods/factories like fromData, toColumns, from/toJson
• A change to expose some of these helpers for 3rd party generators
• All/nothing flag for enabling dataclass & companion generation

This would enable me and others to author 3rd party generators, without doing something cloogy like binding to the moor output, or forking and forgetting (i.e. #114)

For more info on my generator, I'm interested in:

• leveraging freezed, which would make companion classes unnecessary due to nullable copyWith along with other DX benefits
• exploring some bolt-ons ideas, like
  • a @OneToMany method generator
  • taxonomy translation to dataclasses (i.e table declarationAs extends Bs results in
    A implements B with an abstract class B if necessary)
  • declarative "form validation" in factories

[simolus3]

Very interesting ideas! I've always liked the idea of writing plugins for other builders.

I think the easiest approach would be for moor_generator to generate some kind of JSON structure that other generators could take as input. We have some existing support for this already, it shouldn't be much work to emit that for each database class.
Since we build_to: cache, those files wouldn't bother users and other generators can take them as inputs without much hassle.

Adding a build option to stop generating companions and data classes sounds great! We can also add some apis into the moor_generator package to make the generation easier for others.
One potential drawback that comes to mind is that we expect data classes to have a certain name and structure. For instance, custom queries in moor files that only select columns from one table would be generated as Selectable<ThatDataClass>, and the generated code uses a specific factory to map a row to that class. We should probably document those expectations then and treat them as part of the public api. But in general I agree with the approach you mentioned so far.

which would make companion classes unnecessary due to nullable copyWith

Note that companions are also used to hold partial data, e.g. for inserts where some columns have default values.

[micimize]

That's a good point about the companions – may have to do some more thinking there. The schema-based approach seems good also – that would open the door to "bolt-ons" that do qualitatively different things than moor's internals.

I promised myself I'd focus on getting a working MVP before trying to refine my DX, so I prob won't get to it soon, but in the meantime I'll be thinking on it 👍