Ribs: [Question] Right approach in passing token across RIBs

Created on 10 Jul 2019  路  4Comments  路  Source: uber/RIBs

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.

Most helpful comment

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.

All 4 comments

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 Dagger DI 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.

Was this page helpful?
0 / 5 - 0 ratings