Add ModelsViewModel and ModelService for fetching AnyLogic model metadata

[kofi-k]

No description provided.

[Erikvv]

I found in the LanguageManager that this is does not trigger a re-render. Probably because it is not in the Composable tree.

[kofi-k]

Not sure how to explain this but if it is read inside a composable, it will trigger a recomposition.

and i know the basic rule is that when a composable reads a State<T> during composition and that state changes, compose re-renders.
If you never read it in composition, nothing happens.

[Erikvv]

Usually the "Repository" is simple and the "Service" more complex. But here it is the other way around

[kofi-k]

Maybe the confusion comes from mixing backend naming conventions with frontend/Kobweb architecture? 🧐 I don't see anything wrong with the setup itself, hmm

[Erikvv]

I wonder if we can have a more pure implementation of the ViewModel pattern like in https://github.com/google-developer-training/basic-android-kotlin-compose-training-unscramble/tree/main/app/src/main/java/com/example/unscramble/ui

Put the state in compositionLocal so it can be accessed from all the ModelCard components. Like I do with the LanguageProvider:

lux-website/site/src/jsMain/kotlin/com/zenmo/web/zenmo/core/services/localization/Language.kt

Lines 44 to 51 in 8649155

	@Composable
	fun LanguageProvider(content: @Composable () -> Unit) {
	val language = LanguageManager.language.collectAsState()
	CompositionLocalProvider(LocalLanguage provides language.value) {
	content()
	}
	}

[Erikvv]

Please let me know if we're kind of on the same page.

[Erikvv]

I wonder if we should enrich the "TwinModel" objects before rendering, or if the logic should be put in the card components (and in individual model pages)

[kofi-k]

Im inclined to agree with having the state in compositionLocal, while i worked this, co-pilot suggested this approach and i thought it was a bit too much.

I wonder if we should enrich the "TwinModel" objects before rendering, or if the logic should be put in the card components (and in individual model pages)

I think enriching TwinModel objects should work well and makes it easier to update model pages via the component wrappers. I will try something

[Erikvv]

I think enriching TwinModel objects should work well and makes it easier to update model pages via the component wrappers. I will try something

Ok I mostly wanted to know what you'll build on top of this. Will approve this PR.

[kofi-k]

New changes aligns with ViewModel pattern, i envision how we can also enrich TwinModelCard objects from here before collecting it in composables.