To ensure it's accessible on both the Route object and Request objects. The value is currently available on the route object alone.
Proposed by @gabsullice in #2971562: Refactor/clean-up Routes.php.
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 2971649-21.patch | 17.32 KB | gabesullice |
| #21 | interdiff-17-21.txt | 6.78 KB | gabesullice |
| #17 | 2971649-17.patch | 16.34 KB | gabesullice |
| #17 | interdiff-12-17.txt | 4.64 KB | gabesullice |
| #12 | interdiff-10-12.txt | 5.95 KB | gabesullice |
Comments
Comment #2
gabesulliceFirst pass, let's see what testbot thinks.
Comment #3
gabesulliceD'oh
Comment #5
gabesulliceDerp. This should apply when #2953207: Can't get the right target type when filtering on relationship with bundle-specific target entity type lands.
Comment #6
wim leers#5: that happened! Now retesting.
Comment #7
wim leersThe changes in this class feel out of scope based on the issue title and summary.
These changes look fine, but they got me thinking…
… what if instead of inspecting this, we'd simply check whether the route has a
resource_typeroute parameter?Because all of these things only need to happen in that case.
Then we wouldn't need these classes calling a method on
Routes!I think I'm missing something… 🤔
I sure like seeing this vast simplification three times!
Comment #8
gabesulliceI reduced the scope of the changes quite a bit. Now it just cleans things up to use the standard flag. There is still a CS fix in there and I'm still removing an unnecessary check.
I like the cut of your jib. Lower in the class, we do this:
So, we'll still have/need that method regardless. It makes sense to just use it for the "applicability" test though.
Elsewhere, we can just check manually for the request attribute, rather than having that overcomplicated
hasJsonApiParametersto do this for us.Aye.
Comment #10
gabesulliceShoot, I borked the patch. Correcting...
Comment #11
wim leersNit: Once "flag", once "key".
Comment #12
gabesulliceComment #13
wim leers7 files changed, 57 insertions, 80 deletions.Nice!
Maybe I wasn't clear enough. Let me play devil's advocate.
Why not just
instead of
?
Comment #14
wim leersBTW, zero matches when grepping for
_is_jsonapiinjsonapi_extras! 👌Comment #15
gabesulliceIt seemed like it was nicer to use the existing public static method already in place and not tie the enhancers to the implementation internal to the
Routesclass. IOW, the knowledge of how the resource type is stored in the route defaults is kept inside theRoutesclass and not implicitly depended upon in the enhancers.I'm truly ambivalent though. If you feel strongly, I'm happy to go with your suggestion.
Comment #16
wim leersGood argument!
My rationale for proposing #13 instead was to not have one class call another class' public static
@internalmethod.Neither is perfect, both can be argued for. I don't have a strong preference. I just want us to careful consider all options. So that we hopefully don't have to revisit this again. Let's go with yours.
Just one last nit:
This is the inconsistency being cleaned up. Sometimes code was inspecting the route option, sometimes it was calling this method on
Routes. But note that we're still not being consistent:DefaultExceptionSubscriberis now the outlier.Comment #17
gabesulliceNice remark. I like where that led me.
Comment #18
wim leersI didn't know where my remark would lead, but I'm glad to hear you liked it and made the patch quite a bit simpler thanks to it :)
One final nit now that we're renaming this function anyway: we're not getting the resource type (a
\Drupal\jsonapi\ResourceType\ResourceTypeobject), but the resource type name.Oh and there are 5 unused
usestatements causing CS violations, easy fix!Comment #19
wim leersBumping to because this makes JSON API's code base less brittle and more maintainable!
Comment #20
gabesulliceComment #21
gabesulliceComment #22
wim leersSimpler & more robust code AND nearly 30 LoC less. ✅
Comment #24
wim leers🎉
Comment #25
wim leers