-
-
Notifications
You must be signed in to change notification settings - Fork 158
Attribute Naming Conventions #293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Instead of setting the field name straight on the properties or introducing a new setting (keep code simple), we could just use Somewhat related, Opting in would be the default and to opt out of serializing a field,
|
If overriding the name is a concern, |
I think using the existing JsonApiDotNetCore/src/JsonApiDotNetCore/Configuration/JsonApiOptions.cs Lines 144 to 148 in 390db09
One thing to remember is that the existing attributes provide more options than just name overrides. I've enumerated these other configuration properties below:
So, while I think our target should be enabling resource definitions that do not require these attributes, I don't think we should dispense with them altogether. Also, inferring relationships based on types can get tricky. This is not a safe assumption:
There are some reference (class) types that would be considered "simple" types (e.g. {
"data": {
"attributes": {
"key" : {
"nested-key": "nested-value"
}
}
}
} An alternative to this is to try to discover all resources and then determine their relationships by looking for properties where the property type is a registered type on the graph (or the property type is an enumerable of a registered type -- This is an interesting idea:
But, I have a couple reservations here:
I think it may be confusing if users try to use established Newtonsoft.Json features and then they just don't work because we aren't simply doing
JsonApiDotNetCore/src/JsonApiDotNetCore/Models/ResourceObject.cs Lines 6 to 13 in b6ce80d
Because of these reasons, I believe we should keep the existing attributes. They can be used as overrides when there are exceptions to the established convention, or extra configuration is required that is specific to the attribute (e.g For this iteration users should be able to change models from: public class Article : Identifiable {
[Attr("name")]
public string Name { get; set; }
[HasMany("authors")]
public List<Person> Authors { get; set; }
} To: public class Article : Identifiable {
public string Name { get; set; }
[HasMany("authors")]
public List<Person> Authors { get; set; }
} And after additional planning and design, I think we can achieve the following. This will require significant changes to how the public class Article : Identifiable {
public string Name { get; set; }
public List<Person> Authors { get; set; }
} |
With respect to removing attributes, this can be done using the JsonApiDotNetCore/test/UnitTests/Models/ResourceDefinitionTests.cs Lines 103 to 119 in b6ce80d
Or create two distinct models (a resource and db entity), mapped at the service layer. Currently undocumented, but available since v2.4.0 (#112 via #344, #352). In the example,
|
Not sure what the difference between The idea with I'm guessing it's not feasible to go from |
They are the same. The property is called
This is the main part of the project. If all you want is serialization I recommend one of the other .Net libraries. Serialization is a small component of this project and I don't think it will be pulled out into a separate package anytime soon (unless someone else is willing to do it). I personally, don't have the motivation to separate it for the sake of separation. FWIW we do have plans to separate the ORM layer in an upcoming release.
Yes, I'm aware of what But, with all that said, I think I’m in agreement that we should probably honor |
Feat/#293: Naming Conventions, Improvements to AutoDiscovery, and ResourceDefinition
It would be great if we could define an app-wide naming convention for attributes and relationships with default options. So, instead of:
You would specify a convention:
A possible interface for
AttributeNameConvention
might be:The text was updated successfully, but these errors were encountered: