In our app we have a number of abstract models that hold common code for all models that extend from it. As I am converting to WarpDrive I can convert the common attributes into traits just fine, but I am wondering where the implementation code from the abstract class should go. It seems I can put it in an extension for now, but from what I understoof these are more of a helper for migration. So in a world of schemas and interface types, where would that code live?
#Converting abtract model hierarchy to new WarpDrive schema
viscid totem
viscid totem
I tried to build a minimal reproduction repo for my problem.
See here: https://github.com/dagroe/wd-hierarchy-example/tree/main/app/data
There is a base-job which used to be the abstract parent class and a job that "impements" it, along with the base-run and run.
Each base-job can have multiple base-runs but base-job also holds a bunch of code that all jobs have in common.
So the question is where this code would live in an ideal world (without abstract classes / model inheritance) 🙂
tranquil ravine
there’s a number of different patterns that are good - which to use will depend on your use case and some of them are even pretty easy to pull off if you already have the extension
- functions (my usual route) - which are esp nice as they double as helpers
- services
- paired state objects (especially easy if you have an extension you’re starting from)
These are the three approaches I’d reach for most of the time
You may also decide to move some of the functionality into schema
For that you’ll want to look at derivations
derivations are more than just a way to calculate state from other state - since they can return anything you can use them to return functions, services, and all manner of other stuff
but they are kinda intentionally unwieldy to set up - because the idea is that you should only use them for super common things vs one off things