Allow setting 'isSortable' on Schema generated fields not only smart fields
yoadsn opened this issue · comments
Expected behavior
When specifying the name of a field on the "collection" configurator (usually used for Smart Fields) with the "isSortable" property - it would use that value and not the default "false".
Actual behavior
The field is duplicated in the schema.json file and as a result in the UI as well (well, it basically generates a smart field with the same name as the native field)
Context
We are using mongoose - but this seems to be relevant to any Liana implementations.
At the core of the issue, the need to set field properties for fields which are derived from the ORM schema. Some properties like "isRrequired" can be inferred from the DB schema definition, others like "isSortable" are not.
Still, for performance reasons we would like to limit which fields are available for sorting by.
Ideally, if we use the forest-express modules collection export - the one that is used for smart fields and smart collections etc., we could just specify the name of a db derived field with the isSortable value set to false which would override the default true.
This is not working since:
here the collection configurator concats field defs instead of possibly merging them.
The formatter for the field options here does his job by parsing the value correctly.
Of course, conflicts nay arise, so I would gate those "extensions" to native fields with only valid settable attributes and a clear override priority.
The existing field duplication behaviour to me seems like a bug - either throw on such cases blocking this option or properly implement a merge.
Hope this helps!
Hi @yoadsn,
If I read well, you want to have the opportunity to override the "native" fields default configuration using Liana.collection function (especially the isSortable value).
This is not the current purpose of Liana.collection; fields declared here are supposed to be added Smart Fields or Relationships. Native fields should be already well configured and should not need manual configuration changes.
If you want to deactivate the sorting, according to the ForestAdmin vision, it should be done from the UI configuration panels. With this in mind, I would consider this issue as a feature request to enable sorting activation/deactivation on specific fields.
What do you think about this idea?
Thanks you @arnaudbesnier for clarifying that - I see this in a slightly different light.
Since I have been working for a while with ForestAdmin, I have come to realize the limitations of setting ui logic (or sometimes it is business logic) from the Forest layouts configuration.
Generally speaking
The fact that such rules cannot be maintained and tracked as part of the source code is a big flaw in dev driven processes. The "layouts" concept today from a developers' point of view is vague, opaque an inflexible. Also, copying between envs and across teams has some existing bugs and inconsistent behaviors. Our entire CI/CD process is automated - but still the layouts have to be manually done when we deploy - in 2020 this is insane.
About sorting as a UI decision
Allowing to "sort" is not only a decision of the UI but rather a decision of the model designer first. The store has to be properly setup to allow sorting in terms of performance before allowing such an option in the UI. Only then can a layout designer decide to turn it off (if available at all).
About the design concepts of Liana
Although the Liana.collection is meant to be for adding fields and other aspects (actions, segments - i.e extending the schema) - the mongoose or sequalize schemas may not be able to represent all needed model customizaitons. Hence limiting the developers to "extending only" would be a pain point going forward anyway. (even if sorting was a UI only thing).
Consider things like array of enums, which exists in mongoose but not supported in Liana today (it just creates a simple string array in the liana schema) - this could be a valid point of extension assuming mongoose has a problematic support. Even "hooks" which mongoose supports may not cover all use cases of aspect decorations.
What if we wanted to hide some fields which are technical /sensitive in nature but still want to use them in virtual fields? Hiding fields is another use case..
I look at the mongoose (or sequalize) schema as a way to define a Liana model, but not the only way to define it - in my opinion you should move liana-express in a direction where a developer could develop it's own "liana-X-express' layer according to his logic if needed but adding extension points are a natural part of that vision for cases where the DB model is a close-enough starting point.
What do you think? Would love to discuss more over slack if it helps.
Ok,
For your CI/CD needs did you ever consider using our toolbelt?
https://github.com/ForestAdmin/toolbelt
You can automate your layout deployments with it.
I agree with your thought about the sorting.
You're the first person requesting for this.
And providing you such experience, would request a lot of work (that we'll probably execute on day) but that would currently defocus the tech team from it's current missions.
As a workaround, for the isSortable option, you can override the .forestadmin-schema.json values for the field you want. It should do what you are waiting for. The downside is that, every time the schema is recomputed, the values will be reset to their default values.
About your last point, the full liana implementation is open-sourced and not such a complex layer, feel free to fork the codebase and suggest improvements.
The team is relatively small today (regarding all the things to do we have in mind) but we'll keep growing. Such improvements will come for sure, but I can't provide any ETA.
@arnaudbesnier Thanks for being open!
Yes, we have attempted using the toolbelt but last we checked it did not support the new schema structure so it fails with the new Liana. (Reported that to Louis about 1m ago).
But even when it works, the layout copy is always all-or-nothing, merging, when working with multiple developers is eventually going to be needed - I can 100% see how complex it would be to support a code-based layout and did not expect that to happen - just pointing out that if we had all the resources in the world (😍) the architecture should lean towards that.
Regarding the sorting - no worries! there are many workarounds (like overriding the path and filtering out unwanted sorts). Filddeling with generated code is where I draw the line for my team - this usually just leads to bigger problems down the road.
Would you accept PR's on the core Liana implementation? (or the mongoose implementation)?
We feel comfortable working on this code since we keep reading it all the time to figure out how things should be done so this is a possibility for mutual benefits.
BTW.. Forest is AWESOME!