Most of my modules require interaction with remote API's which require token for authentication. I was wondering what the right approach would be. Two come to my mind
(i)My Auth RIB completes authentication and passes on the token as a dependency to the next child RIB and so on. All RIBs (which require token) would now need to declare token as dependency and acquire it from the parent RIB. There is a bit of boiler plate involved
(ii)My Auth RIB completes authentication and stores the token locally. Any RIB which wants to use the token will query the local storage and procure the token. This takes off the dependency from the parent but increases the variants.
At Uber, we'd almost always to with (i).
Having a deep and properly scoped RIB tree means that we can limit the Auth token to only part of the RIB tree where it makes sense. For example the LoggedOut RIB would never be able to even access the token as this makes no sense.
To avoid the boilerplate we use Motif (https://github.com/uber/motif) on Android which is a layer atop the Dagger DI framework. On iOS, we've build Needle (https://github.com/uber/needle) for this.
At Uber, we'd almost always to with (i).
Having a deep and properly scoped RIB tree means that we can limit the Auth token to only part of the RIB tree where it makes sense. For example the LoggedOut RIB would never be able to even access the token as this makes no sense.
To avoid the boilerplate we use Motif (https://github.com/uber/motif) on Android which is a layer atop the
DaggerDI framework. On iOS, we've build Needle (https://github.com/uber/needle) for this.
Thanks for the reply @rudro . I will definitely take a look at Needle. Just one follow up question regarding scoping. Which of these two would you prefer in this case & why
(i)Passing the token as parameter to the RIB's build method
func build(withListener listener: TabListener,token:AuthToken)
(ii)Do you delcare it as depedency which is to be satisfied by the parent's component as described earlier
So for all the RIBs that need this token, we'd do (ii). See the player1Name in this file : https://github.com/uber/RIBs/blob/master/ios/tutorials/tutorial4-completed/TicTacToe/ScoreBoard/BasicScoreBoardBuilder.swift
The name (token in your case) get's added to the DI graph here :
https://github.com/uber/RIBs/blob/master/ios/tutorials/tutorial4-completed/TicTacToe/LoggedIn/LoggedInBuilder.swift#L47
Once the root interactor get's the name/token it passes it to the root router which in turn passes it into the child builder using (i) and the child builder then gives it to the component to put on the DI graph.
https://github.com/uber/RIBs/blob/master/ios/tutorials/tutorial4-completed/TicTacToe/Root/RootRouter.swift#L54
Bit confusing, but hope it made sense.
Summary: The RIB that has the token, passes it to it's child RIB via an argument in the build call. The child builder then gives it to it's own Component to put on the DI graph. From this point on, all children and grand-children use the DI dependency protocols to "ask for" the token and get the token from their parent.
@rudro This actually makes it very clear. Thanks for taking time to answer this.
Most helpful comment
So for all the RIBs that need this token, we'd do (ii). See the
player1Namein this file : https://github.com/uber/RIBs/blob/master/ios/tutorials/tutorial4-completed/TicTacToe/ScoreBoard/BasicScoreBoardBuilder.swiftThe name (token in your case) get's added to the DI graph here :
https://github.com/uber/RIBs/blob/master/ios/tutorials/tutorial4-completed/TicTacToe/LoggedIn/LoggedInBuilder.swift#L47
Once the root interactor get's the name/token it passes it to the root router which in turn passes it into the child builder using (i) and the child builder then gives it to the component to put on the DI graph.
https://github.com/uber/RIBs/blob/master/ios/tutorials/tutorial4-completed/TicTacToe/Root/RootRouter.swift#L54
Bit confusing, but hope it made sense.
Summary: The RIB that has the token, passes it to it's child RIB via an argument in the build call. The child builder then gives it to it's own Component to put on the DI graph. From this point on, all children and grand-children use the DI dependency protocols to "ask for" the token and get the token from their parent.