In theory yes, in practice you’ll have to implement it yourself. You’ll find that this is the answer to a lot of questions in Solid. The opportunities are huge in theory, but in practice there is a lot of work to be done.
I think in principle that’s the idea of what my Soukai library does. To use your example with a Customer, you can do this:
class Customer extends SolidModel {
static fields = {
firstName: FieldType.String,
lastName: FieldType.String,
shippingAddressUrl: FieldType.Key,
billingAddressUrl: FieldType.Key,
};
public shippingAddressRelationship() {
return this.belongsToOne(Address, 'shippingAddressUrl');
}
public billingAddressRelationship() {
return this.belongsToOne(Address, 'billingAddressUrl');
}
}
class Address extends SolidModel {
static fields = {
streetName: FieldType.String,
stateOrProvince: FieldType.String,
postalCode: FieldType.String,
countryName: FieldType.String,
};
}
And this is how you use it:
// To create a new customer...
const customer = new Customer({ firstName: 'John', lastName: 'Doe' });
customer.relatedShippingAddress.create({ streetName: 'Foo bar', ... });
await customer.save();
// To retrieve an existing customer
const customer = await Customer.find('https://my-pod.example.com/customers/123');
console.log(`Hello, ${customer.firstName}!`);
The code above works in practice, that’s what I’m doing in my apps (take it as pseudo-code though, I haven’t run this code).
Potentially, my library could be combined with shapes so that you don’t have to define all those classes and fields manually. You could generate them from a local shex file for development, or from a url if you want to generate models at runtime. That’d be similar to what shex-codegen
is doing in practice today (I think, I haven’t used this library myself). But I don’t have any plans to do this anytime soon, I haven’t found the need to declare models by hand so hard. If anything, I prefer it because it gives me more flexibility.