Do not create permanentNavModel inside ParentNode. Provide it via constructor to ParentNode

[KovalevAndrey]

Description

Fixes: #604

Using PermanentChild composable function, we're delaying adding a child to the ParentNode until PermanentChild is invoked. This can lead to many problems as the appropriate Node will be created only when composable is invoked. Additionally, there's a lot of complexity associated with making sure that we're using only the same instance of PermanentNavModel in the cases when one is provided to the constructor.

This PR removes internally created PermanentNavModel and forces users to provide it from outside

Check list

• I have updated CHANGELOG.md if required.
• I have updated documentation if required.

[LachlanMcKee]

Will this break the code within StatefulNode1.kt?

Just so I understand, it's now mandatory to pass in a NavTarget to the PermanentNavModel constructor?

Perhaps we should update PermanentNavModel to throw an IllegalStateException if there are no NavTarget's provided? Could we also consider removing the vararg then, as this will definitely lead to issues

[KovalevAndrey]

good catch

[CherryPerry]

I think we should just ignore if there is no child of the specific type. Otherwise we break functionality where you add a child later. Or maybe provide some optional renderer function.

Just so I understand, it's now mandatory to pass in a NavTarget to the PermanentNavModel constructor?

Why it should be so? We still have add/addUnique operations to add nodes later.

[KovalevAndrey]

I feel like if you have a logic of adding a child later at some point it shouldn't be a part of PermanentNavModel

[LachlanMcKee]

perhaps leave it as is for now, and consider changing this behaviour in 2.0?

[LachlanMcKee]

@CherryPerry my usecase is that I have a PermanentChild that is added immediately (via the constructor) and is only shown once the data is loaded (unfortunately in my usecase the ParentNode is responsible for when to show the PermanentChild based on Output of whether the state is loaded or not)

Without this change, the PermanentChild would not correctly start the business logic when added via the PermanentChild constructor (well actually it can, but it renders the wrong one at the moment)

[CherryPerry]

Anyway, we are breaking existing use case without providing alternative, when you want to add your permanent child later after some flag is triggered. Now you can via if (myCheck) PermanentChild(NavKey.AddMe).

[KovalevAndrey]

I reverted it back so we can add keys later

[KovalevAndrey]

Or we can observe permanentNavModel in composition to render permanent children

val isAddMeExists = permanentNavModel
    .elements.
    .mapState(scope, SharingStarted.WhileSubscribed()) { navElements ->
         navElements
             .find { it.key.navTarget == navTarget } ?: false
     }
     .collectAsState()

if (isAddMeExists) { PermanentChild() } 

otherwise it's difficult to track issues where you forgot to add a key

[KovalevAndrey]

Perhaps, can be added to an overloaded PermanentChild while default one fails