thlorenz / rid

Rust integrated Dart framework providing an easy way to build Flutter apps with Rust.
63 stars 4 forks source link

Multiple stores/multiple models #17

Closed ghost closed 3 years ago

ghost commented 3 years ago

So I'm currently building a music player which has several models that need to be stored in rust (file locations, song/album/artist objects, settings etc.). The problem I'm having (I haven't written any rust yet I'm still reading through documentation) is this:

"exactly one main model per application" -> so one store per app "a #[rid:store] as a superset of a #[rid::model]" -> so one model per store

taken from rid::store

So my mind immediately goes to: so I can only have one model per app?!

Which of my assumptions is wrong here? Am I meant to have one store with multiple models or multiple stores holding single models?

MGlolenstine commented 3 years ago

I haven't written any code for RID yet either, but with Data-driven-approach, there usually is just one store with models stored in it. Here in RID that limit's set because you have to know how much you're going to export before you sync FFI code. And for RID, it's generated for one store. It might change/extend in the future, but if you follow DDA, you won't need more than one.

thlorenz commented 3 years ago

@MGlolenstine is explaining this correctly and I want to clarify since I feel there might be confusion between model vs. store.

It's not one model per app, but one store per app that gives you access to all app data. That app data can include multiple models.

The idea is similar to redux that you have one app and thus also one app state. All sub states / models are reachable via that main state. I explain the philosophical/architectural aspect of this in the rid::store documentation that you also mentioned. It says one main model per app (which is the store), not just one model. Maybe we can express that clearer in the docs to avoid confusion.

Here is an interesting read about the same topic in context of the redux library.

Aside from the architectural benefits having only one store allows rid to guarantee memory safety when accessing data from Dart and/or multiple threads since any access goes through the store which is read/write locked. It wouldn't be impossible to make this work for multiple stores, but would be a lot trickier and error prone.

I hope that makes sense, if not feel free to ask more questions. It is very possible that I'm not explaining this very well in the rid documentation.

ghost commented 3 years ago

Thanks for the reply @MGlolenstine and @thlorenz. That does clear it up for me, it might be worthwhile considering adding a line or two about multiple models in the docs.