3 ms·
I see a lot of folks who are a lot smarter than me crapping on this, but I think it could be really useful. I've thought about the problem before of how to shar
by dabernathy89 10y ago
I see a lot of folks who are a lot smarter than me crapping on this, but I think it could be really useful. I've thought about the problem before of how to share complex rules between front-end and back-end safely, and came up with a UI for it:
https://dabernathy89.github.io/vue-query-builder/ https://dabernathy89.github.io/vue-query-builder/
I honestly didn't put too much thought into the actual structure of the JSON, so I wonder if there is someway I can now integrate JsonLogic into the query builder.
Good work!
- foota 10y agoThis seems a lot like Facebook's graphql
- couchand 10y agoI would suggest that, at first glance, your structure is actually preferable for most applications where this would be useful. The real advantage of a DSL is when it provides a concise way to solve a specific problem domain. The OP just provides a verbose way to describe a general problem domain, without any benefit of regularization. Your schema, on the other hand, uses explicit node names and types, which should make automated analysis much simpler and less error-prone. The few changes I'd suggest are mostly just cosmetic: standardizing the schema (the type radio seems to imply the operator equals), renaming properties (why selectedOperator when just operator will do?), and maybe compressing levels where appropriate, for instance the query-builder-group could itself have the logicalOperator property.
- dabernathy89 10y agothat makes sense - and thanks for the feedback!
- deleted 10y ago[deleted]