[Question] Accessing Model sub-structures

Hello! Let me begin by thanking you for the amazing framework, I started playing with Stipple two days ago and I find it rather pleasant to use (except for the lack of docstrings, but well, that’s life).

I am trying to develop a fairly complex dashboard to monitor my simulations, and would like to split my model, which otherwise will have more than 100 fields, into several sub-structures for code clarity and maintainability/sanity.

However, I need to be able to read/set those fields from some UI elements like Selector, Checkboxes or plot them.

Is it possible to turn something like

Base.@kwdef mutable struct Model <: ReactiveModel
  group1_field1::R{Bool} = true
  group1_field2::R{Bool} = true
  group1_field3::R{Bool} = true
 
  group2_field1::R{Bool} = true
  group2_field2::R{Bool} = true
  group2_field3::R{Bool} = true

...
end

model = Stipple.init(Model())

function ui()
  [dashboard(vm(model),class = "container",title = "My thingy",[
        heading("Group1"),
           checkbox("Field1", : group1_field1),
           checkbox("Field2", : group1_field2),
           checkbox("Field3", : group1_field3),
        heading("Group2"),
           checkbox("Field1", : group2_field1),
           checkbox("Field2", : group2_field2),
           checkbox("Field3", : group2_field3),
  ])]
end

into something like

Base.@kwdef mutable struct ModelGroup
  field1::R{Bool} = true
  field2::R{Bool} = true
  field3::R{Bool} = true
end

Base.@kwdef mutable struct Model <: ReactiveModel
  group1::R{ModelGroup} = ModelGroup(true, true, false)
  group2::R{ModelGroup} = ModelGroup(true, true, false)
end

and still use it from the ui?

[hhaensel]

It’s done and, as far as I can see, works like a charm. See also my post in PR 43. So now we have

Reactive(v::T) where T = convert(Reactive{T}, v)
r = Reactive([1, 2, 3])
on(r) do r
  @show(r)
end
#non-notifying
r[][3] = 4
#notifying
r[3] = 4

[essenciary]

For me it’s still not clear what Dicts are we talking about. Is this about Stipple.render?

I believe it’s useful to brainstorm features and improvements as they pop-up in different contexts, but to address them properly we should set separate issues for each individual topic with a well defined problem and a minimal working example.