-
I have defined a function to wrap my model to provide it with additional capabilities. const Record = (fields) => {
const BaseModel = types.model({
...fields,
});
const Model =
BaseModel.
volatile().
views().
actions()
...
return Model;
} The BaseModel fields will store some common fields, and I have also encapsulated them. They will go through a factory function like this. const Fields = (value) => {
const Model = types
value: types.optional(
typeof types.frozen === 'function' ? types.frozen<ValueType>() : types.frozen,
value
)
})
return Model;
} When I use these tools to create a store, it looks like this. const MyStore = Model({
baseInfo: Record({
formData: Record({
...
})
})
})
const storeIns = MyStore.create(); Currently, I'm encountering an issue with Record, where I need to dynamically add key-value pairs like [fieldName]: Fields(); to my Record model based on the returned data. form.addFields({
name: Fields('myName'),
age: Fields(16)
}) So how should I encapsulate this function to ensure that mst correctly recognizes dynamically added fields, such as name and age, and incorporates them as part of the entire tree? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
Hi @Linxae030 - this is an interesting use case! I haven't ever attempted something like this. Is there any chance you can put together a CodeSandbox or runnable demo that I could play around with? I don't think I'll be able to give you great advice without seeing it at runtime. |
Beta Was this translation helpful? Give feedback.
-
I was looking into some similar scenarios early on and I came to the conclusion that volatile state or a normal mobx observable are better suited to this use case. The point of the nodes are to provide immutable structures as well as tracking state updates and changes, so if you're adding fields to the model after create it's not the same node anymore. Check out the mst-form-type project if you haven't already. They created a separate model for fields and store the model in a froze type on the form. It looks like you're fairly close in the idea with what you've shown, but you'd probably be better adding items to an array and then extracting them into a view to display properly. If you're looking at just simplifying the creation of stores and do not care so much about the MST semantics, then mobx observable will probably be better for you as any properties you add later will automatically be made observable. HTH |
Beta Was this translation helpful? Give feedback.
I was looking into some similar scenarios early on and I came to the conclusion that volatile state or a normal mobx observable are better suited to this use case. The point of the nodes are to provide immutable structures as well as tracking state updates and changes, so if you're adding fields to the model after create it's not the same node anymore.
Check out the mst-form-type project if you haven't already. They created a separate model for fields and store the model in a froze type on the form. It looks like you're fairly close in the idea with what you've shown, but you'd probably be better adding items to an array and then extracting them into a view to display properly. If you're…