citizenlab
citizenlab copied to clipboard
CL-959
Sorrry, didn't have time. Maybe later 😴
(Watch out: seems tests are not running... probably bc of the force-pushed.)
Warnings | |
---|---|
:warning: | The changelog hasn't been modified |
Messages | |
---|---|
:book: | Jira issue: CL-959 |
Generated by :no_entry_sign: dangerJS against 0c48334566fd42a418f146179596c5f2121888ae
I'm not sure we should go with this. The code is fine, and I'm sure it works, but I think that we want to keep our data layer as clean and normalized as possible. I don't think syncing options and areas through our application layer is a good idea, it will bite us sooner rather than later. Because data manipulations will happen behind the back of our application layer, because the syncing logic will fail or records will be created that skip the AR hooks, because the application will fail with an unrelated error and not perform the syncing.
Given the effort put into this, it must be that I don't understand well enough what pain this is creating today. We have a few places where we need to deal with this exceptional behavior (using areas instead of custom field options for the field), and while it's always nicer to not have these, I don't consider this a great pain or big complexity in the code today. It's all quite contained and small in terms of code. So it must be that for representation, this is a big pain, and I'm not getting yet why.
I understand this is blocking the release of representation, so syncing today to understand how urgent it is to get this out.