Compose's very first recomposition runs synchronously. If you are using

launchMolecule

by the time you get the

StateFlow

returned a single recomposition has run. If you are using

moleculeFlow

then it will emit immediately, although i'm not sure if that involves posting to the dispatcher or not.

Is there a way to mark a connection as "should not be re-used" in okhttp?

Add a header,

Connection: close

Either on the request or the response, and it can be in an interceptor

Do you have a timeline for https://github.com/cashapp/zipline/issues/745 and https://github.com/cashapp/redwood/issues/404? Thank you! 🙂

The latter is done, just blocked on the former

Does okhttp have a way of limiting the maximum number of connections used? I see ConnectionPool allows configuring

maxIdleConnections

but says nothing of maximum total connections allowed to be created/active. I also am not seeing an equivalent of a

connectAcquireTimeout

...

Is it fair to say that https://github.com/cashapp/redwood/issues/380 is a fundamental issue with Redwood currently (at least with a Compose UI frontend)? A simple fix would be to update

text

directly in the

onValueChange

callback, but that's now explicitly creating multiple sources of truth (which may be better than the current implicit multiple sources of truth, but is still not great). I haven't played around much with Redwood other than with the samples, so I'm not sure if this is an isolated issue with

TextField

because

onValueChange

can be called OOB (because of IME, etc...), or if there are problems with other composables as well. In any case, having to handle it for even just

TextField

seems like a high burden to someone using Redwood.

It's not really an issue. More just the cost of doing business.

This sounds like a fairly similar concept as Workflow's

TextController

, which is required for "legacy" views as well, not just Compose, for what it's worth. Ensuring a single source of truth for text inputs is inherently tricky.

Right, I meant issue more as something that has to be dealt with rather than Redwood being broken. I can see this being a typical flow when someone tries to adopt Redwood (at least it was my experience 😅): 1. Start using Redwood with Compose UI 2. Provide a text field implementation with simple mutable state handling like they're used to in Compose UI 3. Scratch their head when the TextField only allows one character to be typed 4. Either give up and assume Redwood is broken (because it works fine in Compose UI) or spend hours debugging until they figure out what's going on 5. Figure out the problem, come up with the solution, implement it Is the plan to have Redwood provide something like

TextController

/

TextFieldState

and put a disclaimer in the readme that this is how text needs to be handled? While in practice this might only affect text, in theory couldn't this affect any component where the value is provided from a callback?

Is there a way to have layout modifiers in Redwood without specifying a scope so they could be applied to any item?

We removed this ability recently. What's your use case?

I want to have some modifiers that are available to any widget. For example the

Modifier.padding

in Compose UI is a freestanding modifier that's not scope-specific. One other thing I wanted to try implementing was

Modifier.clickable

, but I wasn't sure it that'd work at all

I'm not at a computer, but our general usage has been for components that are much higher level where things like padding and the ability to be clicked are properties and not modifiers. Our modifiers are named layout modifiers because they're only meant to be read by the parent layout such as to set things like alignment

I see. Thanks for that context. It's true that I'm really misusing Redwood and so it makes sense that this usecase doesn't align well. Thanks anyway! 🙂

You could create your own Modifier type and add all those things to it

That's a good idea, I'll try exploring that, thanks!

Is there any place where one could see at examples to be inspired as to how “high level” are we talking when you say that? I’d imagine a lot of people will default to designing granular enough components where things like “padding” are needed, potentially falling into a trap that wouldn’t be so good in the long run. If you got any learnings like that while using redwood internally, I’m sure it’d be very valuable to share to the outside world to avoid doing the same mistakes if that makes sense.

Jesse talks about that in the Droidcon NYC presentation. Ultimately it is up to you at what granularity you design, but our intent was to encode our design system components as defined by our design team. They are usually similar to regular widgets (like a Button) but where all the design choices are already made and so you're only deciding between things like primary or secondary style.

We don't really have anything beyond that right now

Yeah I see your point of view, makes sense. Looking forward to hearing more from other teams that try out redwood. Maybe they also end up defaulting to what you’re describing here.

When using paparazzi, is there a good way to run the composables without recording a snapshot? I have a composable that takes a couple of frames to perform an incremental layout process. I want to test that it’s properly laid out in 5 ticks, but I don’t quite care what happens for the first 4. I’m currently passing names ‘frame$i’ as names for the snapshots, but if I make improvements and it can finish in fewer ticks, I don’t want tests to flag it. I really only care that the 5th tick looks right.

Is it possible to use a Molecule function to manage the updating of some status on each item of a list (probably by passing down some kind of provider of composable functions that give a statelflow unique to each item)...?

I'm wondering if it somehow integrates into the recomposition tree of the UI so that when the LazyList puts other items there, then it stops listening to that stateflow and creates a new one, maybe that's the whole point of Molecule? (I've never really used it, I'm just trying to see if it could help solve our use case...)

Giving it a try now... but I'm getting an error in Android Studio that flow operators shouldn't be used in composables... will I have to do

@SuppressLint("FlowOperatorInvokedInComposition")

for each of them? It seems to me that in the context of Molecule presenters there's no real problem in transforming/filtering flows... maybe there's a way for the library to suppress those warnings for it's functions somehow?

Should I create a new

MainScope()

in my

ViewModel

for

launchMolecule()

? It seems like

viewModelScope

doesn't work...

I don't think there's any healthy way to pass the `Activity`'s scope there, and I would really like to keep all this code in the view model...

Nope... still gives me a

java.lang.IllegalStateException: A MonotonicFrameClock is not available in this CoroutineContext. Callers should supply an appropriate MonotonicFrameClock using withContext.

error...