https://kotlinlang.org logo
Join Slack
Powered by
Hi <@UHAJKUSTU>. I’ve asked many many many questio...
# compose-desktop
r
Hi @Arkadii Ivanov. I’ve asked many many many questions regarding implementation of decompose library. I’m using jetbrains compose, decompose, mvikotlin, ktor, Now I’m trying to navigate to first screen when api throws authentication error. How can I pass router to api service?
a
Hi!
How can I pass router to api service?
There is not enough context to answer precisely, but you can pass Router via constructor of the 
api service
. Just as normal object. But it may result in coupling. Maybe you can listen for api errors in the root/parant component (owner of the Router)? The 
Router
has method 
Router.navigate
. You can supply any stack you want. E.g. 
Router.navigate { listOf(Configuration.Login} }
, will destroy the current stack and navigate to the Login screen. If the Login screen is already in the back stack, it will be resumed. If not, it will be created.
r
What about adding goToLogin fun to RootCompoent and pass RootCompoent to apiService?
a
This can also work. If you are fine with the fact, that ApiService will depend on the RootComponent.
r
https://github.com/arkivanov/Decompose#why-decompose I read the docs and you have stated that components won’t be destroyed . So we could pass it as a weak reference ?
a
They are not destroyed while in the back stack. But once removed, they are destroyed. Just like Android Fragments.
Probably I need to elaborate this point in the docs
r
Yes but root component will stay there while app is running isn’t it?
a
Yes it will stay
r
I’ve a repo for every component which encapsulate base ApiService. I’ll create AppComponentContext which extends ComponentContext with an extra ErrorHandler class which receives RootCompont. With this error handler I can handle authentication errors in every repo class
a
This is the second time I'm asked about 
ComponentContext
extension. Decompose is quite flexible, so I came up with a solution. Would be nice if you try and provide your feedback in the issue.
Updated the previous message with the correct link.
r
Here error handling middleware class
a
Yep, looks valid.
Btw MVIKotlin, Reaktive and Decompose - full house of the libs I'm maintaining!
r
As the middleware will be available from everywhere via AppComponentContext we can bind error messages to Store state then to model
a
Yes. There is just one downside, you will need to use the middleware every time. As an option, you could try to encapsulate this logic into your networking layer, and broadcast errors from there. So you could subscribe to errors in the Root component and navigate accordingly.
r
But there may be errors only child component is aware of processing logic
a
That's makes sense. Then your solution should work.
r
Or we can implement as BackPressedDispatcher?
Maybe error handling mechanism will be decompose build-in component?
a
BackPressedDispatcher is like a relay. You can listen for events, and send Back events to it. Router is also a subscriber. It navigates one by one. But you might need to replace all current stack with just one Login screen. Better to not mess with the BackPressedDispatcher and just call Router manually.
At the moment I don't want add such a logic. It can be easily done client-side, and every use case is different.
r
I mean If we have component tree like this: RootComponent -> DashboardComponent -> ListComponent every child component can dispatch error handle or pass to upper level
a
You can extend ComponentContext with your own error handler. Or just pass it via constructor to all children. It's up to you.
r
Hey. How can I handle appbar navback button press by default? I couldn’t find sample code How can I access backpress handler ?
a
Is appbar is part of the child or parent?
r
Every screen has it’s appbar
a
In this case here is an example.
Details
responsibility ends once Back button is clicked in the appbar. It is Root's responsibility to navigate back.
r
I know it. I’m asking about the default handler. When I set handleBackButton = true and click system back navigation it automatically pops back. But how can I access this handler and bind to my appbar navbutton?
a
Looks like you are trying to use the 
BackPressedDispatcher
in your child component. Normally children should not be aware of the navigation logic. Navigation logic should be Parent's responsibility. Children should only tell Parents when they are finished, so the Parent can decide what to do (e.g. execute 
Router.pop()
). But if you really want, you can call 
backPressedDispatcher.onBackPressed()
in a Component.
r
Yes I’m trying to implement default back press handler because not every component needs custom handler for this event. Thank you. Now I’ll try
If I pass the handler to @composable functions via ambients and use it as default onclick handler is it ok?
a
It will work. However it is better to use Components's BackPressedDispatcher instead. At the moment they are same instances every time, but this might change in future, so each child will have its own instance. Your Composable function can talk to its component (e.g. call a method).
r
Thank you. How can we implement same logic for both backpress and navback click events? For example: We have a screen where some data will be changed and when user tries to go back it must show dialog
a
In this case I believe this logic should be in the Child component. It can hook to the 
BackPressedDispatcher
and to the AppBar Back button. In both cases it should show a dialog and once confirmed, the Child component could emit an 
Output.Finished
(or just call a callback passed via constructor, whatever you prefer).
The Dialog should part of the Child's state, obviously.
Depending on your requirements, you may want to show the dialog in the Parent. In this case children should tell the Parent that the AppBar's back button is clicked. And then the reset will be handled by the Parent. The Parent should hook to the 
BackPressedDispatcher
in this case.
r
Thank you can you tell me the proper way to hook to backpressdispatcher in component?
message has been deleted
a
Yes, you should use 
register
method. And don't forget to unregister at the end of lifecycle. You should return 
true
in 
onBackPressed
method, so the back navigation is blocked at this point.
r
Or smth like this
a
Yes, the last example is correct
Maybe better to register in onCreate
r
You mean ?
Copy code
lifecycle.doOnCreate {  }
a
Yep. Or 
lifecycle.subscribe(onCreate=, onDestroy=)
r
Then what about binding labels. In the sample app it was bound in init block
a
They are normally bound using 
binder
, which handles the lifecycle
r
Hi @Arkadii Ivanov how can we change appBar if we implement single appBar for the app? Now I’m thinking about changing content depending on screen size. For example when app opened in a phone device ui flow will be root -> list -> item view and when app opened in a tablet ui flow will be root -> list & item combined
a
Hi. You take some examples from here: https://github.com/arkivanov/Decompose/discussions/47
Open in Slack
PreviousNext
Powered by