Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decompose out multiple circuit internals for reuse + publicize CircuitContent #1024

Merged
merged 3 commits into from
Nov 28, 2023

Conversation

ZacSweers
Copy link
Collaborator

@ZacSweers ZacSweers commented Nov 28, 2023

This allows more granular use of CircuitContent and bringing your own presenter/ui instances. This allows more advanced presenters that could choose to pass composable lambdas in as state properties with tight linking of shared state.

It's a little verbose right now as I'm not sure what the best spots are to offer default values or not, but I think that's ok since these are advanced use cases and we can get feedback now. It doesn't take a particularly strong opinion on how to do this, just opens up doors.

// A state with nested content controlled by the presenter.
// Alternatively, the state could expose a presenter factory for the nested content too
data class MyState(
  // other props
  val nestedContent: @Composable () -> Unit,
)

// In a presenter with an injected anotherPresenterFactory and circuit instance
@Composable
override fun present(): MyState {
  val sharedState = remember { mutableStateOf("") }   

  val nestedPresenter = rememberPresenter(...) {
    anotherPresenterFactory.create(sharedState)
  }

  return MyState(...) {
    CircuitContent(NestedScreen, nestedPresenter, ui = rememberUi(screen, ..., circuit::ui))
  }
}

// The UI slots it in
@Composable fun MyUi(state: MyState, modifier: Modifier) {
  Scaffold(modifier) {
    state.nestedContent()
  }
}

…tContent

This allows more granular use of CircuitContent and bringing your own presenter/ui instances. This allows more advanced presenters that could choose to pass composable lambdas in as state properties with tight linking of shared state.
@ZacSweers
Copy link
Collaborator Author

CCing some possibly interested parties @bryanstern @chrisbanes

@bryanstern
Copy link
Contributor

I like this and definitely have a use case for it.

@ZacSweers ZacSweers merged commit 9f42b87 into main Nov 28, 2023
3 checks passed
@ZacSweers ZacSweers deleted the z/decompose branch November 28, 2023 22:37
@chrisbanes
Copy link
Contributor

chrisbanes commented Nov 28, 2023

I like the idea behind it! I've been using similar with Decompose in a work project, and being able to treat the UI as a big tree has some nice advantages (but downsides too).

I'm not sure on the example listed in the PR though. Feels a bit... messy to me, leaking the layers of presenter, state and UI into each other.

Personally I think only the nested presenter should be in the state, and then the 'parent UI' should be responsible for the rest of it. WDYT?

@ZacSweers
Copy link
Collaborator Author

that's very fair, the example here was more or less tossed together quick and based on some DMs between Bryan and I. For the last bit, do you mean just making the presenter instance a property in the state?

@chrisbanes
Copy link
Contributor

Yeah exactly. It's similar to what Decompose does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants