fix(serializer): honour nested includes in lazy_load_data - #203
Draft
tvdeyen wants to merge 2 commits into
Draft
Conversation
tvdeyen
force-pushed
the
fix-jsonapi-lazy-load-nested
branch
from
August 24, 2026 13:30
62a1897 to
befdc82
Compare
Contributor
|
Amazing. |
tvdeyen
force-pushed
the
fix-jsonapi-lazy-load-nested
branch
2 times, most recently
from
August 26, 2026 16:50
566b21e to
0100d28
Compare
jsonapi-serializer decides whether to emit a relationship's linkage from `includes_list.include?(key)`, but the top-level includes are a flat list of dotted symbols and each sideloaded record is handed its parent's includes_list rather than the scoped remainder. So enabling `lazy_load_data` suppresses linkage for every relationship of a nested resource -- including the ones that were requested -- which makes it unusable beyond top-level relationships. Prepend a patch onto FastJsonapi::SerializationCore that matches the base key of each requested include path and threads the scoped remainder into each sideloaded record, so lazy_load_data only suppresses relationships that were genuinely not requested at that resource's position in the include tree. It is loaded at boot from the engine (the target is a gem constant, not autoloadable) and is inert for relationships that do not set lazy_load_data.
tvdeyen
force-pushed
the
fix-jsonapi-lazy-load-nested
branch
from
August 26, 2026 17:39
0100d28 to
9bae754
Compare
Emitting linkage for relationships that were not requested via `include` is surprising and triggers N+1 queries on the server, so relationships now set `lazy_load_data: true` and emit their `data` only when requested. The element tree is the exception and stays eager: `all_elements`, `elements`, `fixed_elements` and the recursive `nested_elements`. A tree of arbitrary depth cannot be expressed as an `include` path, and clients rely on the top-level `elements`/`fixed_elements` linkage as the entry points from which to walk `nested_elements` down and reconstruct the page's content.
tvdeyen
force-pushed
the
fix-jsonapi-lazy-load-nested
branch
from
August 26, 2026 18:01
9bae754 to
79ddb46
Compare
tvdeyen
marked this pull request as draft
August 27, 2026 21:31
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
jsonapi-serializer'slazy_load_datais meant to omit a relationship'sdatalinkage unless that relationship was requested viainclude. It works for top-level relationships but is broken for nested ones: a relationship emits linkageunless lazy_load_data && !included, whereincluded = includes_list.include?(key)— but the top-level includes are a flat list of dotted symbols (primary_taxon.ancestors), andget_included_recordshands each sideloaded record its parent'sincludes_listrather than the scoped remainder. So enablinglazy_load_datasuppresses linkage for every relationship of a nested resource, including the ones that were requested — making it unusable beyond the top level.This prepends a patch onto
FastJsonapi::SerializationCorethat:includedagainst the base key of each requested include path (soprimary_taxon.ancestorsmarks:primary_taxon, and the taxon's own:ancestors), andWith it,
lazy_load_data: trueemits linkage only for relationships actually requested at that resource's position in the include tree — which lets a serializer stop emitting the unrequested back-references (a taxon'schildrenwhen onlyancestorswas asked for, an option value'soption_type, …) that otherwise bloat responses and create cycles for consumers.Scope / safety
lazy_load_dataanywhere. It's a pure bug fix and is completely inert for relationships that don't setlazy_load_data: true(their linkage is emitted regardless).require(flickwerk/Zeitwerkon_loadonly fires for app-autoloaded constants, not gem code).Testing
Spec added under
spec/serializers/…reproducing the nested case (requested relationship keepsdata, unrequested nested relationship drops it, and non-lazy relationships are untouched). The fix was also validated directly againstjsonapi-serializer2.2.0 in isolation.