For Molecule - is it common practice to cache the ...

# squarelibraries

[Deep Patel]

For Molecule - is it common practice to cache the renderer at the AppTemplateRenderer level like below? Or should we not do this? I'm not sure how efficient the call to rendererFactory.getComposeRenderer is

like this

val renderer = remember(content) { rendererFactory.getComposeRenderer(content) }
renderer.renderCompose(content)

[saket]

That would depend entirely on `getComposeRenderer()`'s implementation. Will your code misbehave or drop frames if it's called on every frame?

[Deep Patel]

Uhm... it's possible it could misbehave, but I'm putting all the heavy logic involving network requests and compute in the presenter. I'm trying to keep the renderer as "dumb" as possible.

[saket]

Right, but this isn't really a molecule question -- it's a compose one. You're essentially trying to figure out whether rendererFactory.getComposeRenderer() needs memoization.

[saket]

if you want to use the same instance on every frame for any reason, you can remember its returned value. If it's cheap to compute because maybe getComposeRenderer returns the same value on every call then there's no value in adding a second caching layer

[Deep Patel]

When would an app ever need to use a different renderer for the same BaseModel type?

[saket]

That sounds like a question very specific to how your app's navigation stack is designed. It's difficult to answer without knowing more about it. What's a renderer? Why does your renderer factory require the model object to return a renderer?

[saket]

I'm also assuming BaseModel is the base type extended/implemented by your screen's model class?

[Deep Patel]

Btw - thanks for helping me here - yes to the BaseModel question.

[Deep Patel]

At a high level the app is built with Compose multiplatform - I'm using app platform for this whole app. ComposeRenderer all over the place to bind the Model from my Presenters