Conversation
Introduces the new code in a separate serializer that inherits from the existing one so that dynamic field enjoyers can opt into the new functionality. However the new field seems to be 100% backwards compatible with the old one, save for some performance hit since we are doing extra work.
|
Thank you, @jtrain. I’ve tested this approach, and it works for our use case. I only needed to apply a simple fix in the
Tweaking the logic to avoid incrementing the level for a We should also update and extend the tests to cover this scenario. I think it’s fine that you removed all the logic for determining which fields to defer—we can derive that from the I agree with this approach. If you’d like, I can refine the logic further and improve the tests (I might need to open a separate PR based on this one due to permissions). Let me know what you think. |
|
@albertisfu great! yes please if you like you can use this PR as your base to make the improvements you've suggested. |
#42 replacement for this PR
@albertisfu here is an alternative approach where we do allow each serializer the ability to filter itself instead of orchestrating the filtering from the parent.
Does this approach work for your use-case? You can see that this cuts down on the logic spread throughout the fields method, and contains the hard work of finding the fields to filter / omit in some helper functions - I'm sure these could be simplified further - they are just gpt code. (for example I don't like
whilestatements as a rule)