Breaking change in data structure

I just had the chance to test the 4.0 and everything looks amazing! I’m sorry I couldn’t test the beta 7 and 8 and keep providing feedback.

Anyways, as I mentioned here I have one small complaint about the 4.0: the (imho unnecessary) breaking change in the data structure of the rules. (now rules is an array of objects and strings (["and" | "or"]), instead of being an array of (nested) objects and having a combinator field for each “level”)

I understand why the change was introduced (in order to implement what I asked in #204), but I think there might have been another way. Since #204 was all about refactoring the UI and since the precedence or the logical operators can be inferred no matter how the UI is represented, I thought that the change wouldn’t affect the actual data structure of the library.

My bad for not noticing that the actual data structure changed and for not providing feedback in #204. I beg a pardon for that.

That said, since the 4.0 was already released (although only 12 days ago) and the breaking change was already done, I don’t think it would be a good idea to do yet another breaking change and revert back to the old export format.

But what could be a good idea is to add another export format (next to sql, json, etc… maybe call it v3 or legacy?) that would export the rules with the old data structure format. I think it shouldn’t be too hard to accomplish, since there is already a mongodb format, which looks quite like the old format.

Not having introduced the BC in the data structure in the first place would have helped reduce the upgrade friction by 100%, but since that ship already sailed, next best thing is to add a “compatibility layer” in the export format. That will probably reduce the amount of work to be done by the users when they upgrade to 4.0.

All things considered, with or without this “compatibility layer”, the 4.0 is looking amazing! Absolutely great job!

[jakeboone02]

OK, 1 and 3 are implemented. convertFromIC and convertToIC as well as isRuleGroupType and isRuleGroupTypeIC are all exported now.

As for 2, this is return statement for convertFromIC:

  return { ...processedRG, combinator, rules };

The combinator comes before the rules, so I think what you’re seeing has something to do with the way JSON.stringify orders object properties. I’ve noticed in the past that the combinator and not properties appear below the rules when using JSON.stringify. I agree it’s not as visually intuitive but I don’t think there’s anything we can do about it short of writing our own stringify method.

[jakeboone02]

Great! I’ll get started on the converter function and let you know when you can test it out.