feat: easier to extend the payload returning the token without having… #5726
Conversation
There was a problem hiding this comment.
Hi @woile.
I'm not sure about this. I see what you're doing, no problem there...
We have, though, deliberately, long-chosen to keep the auth token implementation as simple as possible. We explicitly do want people to re-implement if the packaged solution doesn't meet needs.
(The reasoning here is just fixing the scope of the project — once we allow some extensions, we then allow others and all of a sudden we're maintaining an overly complex view/model/...)
|
Agreed w/ @carltongibson I'd suggest following the solution from #2414. |
|
Yeah, I understand. Keep in mind that there were already 3 PR for this feature, so it looks like a common problem/choice people face. I think mostly because it's a bit counter intuitive (not wrong at all) doing that. Even if we don't merge this PR, I think we could improve the docs, like showing a whole example of how to reimplement the |
|
Hey @woile — sorry for the slow follow-up.
Ultimately I think that's the way I want to go here. An example towards the end of the Fancy taking that on? 😉 |
|
I'll check it out after work! |
Problem
Usually we want to extend the information here, reusing the token, not reimplementing the whole method.
I find it counterintuitive having to copy the whole function again, like suggested here it's not what you'd expect at first, and I start wondering if I might be doing something wrong.
Another solution is calling
superand having to scrap theresponsefor the token, like suggested here usually if you modify this function, you want something related to the user, and you will have to request it again (or the token), because it was already requested in the serializer inside thesuper.Use cases
Similar PR
#4385
#2978
#2151
Tickets related
#2414
Hope it helps!
Regards!