refactor(replies): replace segment button to icon buttons

[mforesti]

No description provided.

[borgoat]

I don't quite get the renaming: it's only partially done, as the table still has the previous name, so it only adds a layer of indirection. Is it really needed at this stage? I understand the code is not that good, and for sure I could have done some things better in the initial modelling, but at this point, does such a refactoring really help?

[mforesti]

My bad, the search/replace did not work properly... 🤦

To answer your question about whether the refactoring is needed, I could not do it in any simpler and faster way without being confused all the time what was it that I was touching: the default recurrence rule? the reply option of the default recurrence rule? the reply option of the instance of the default recurrence rule? etc...
Maybe, I am too old and my working memory is smaller than a goldfish, so it was cognitively less complex for my brain to adopt what I thought had clear definition of the difference entities we use to control how to show whether somebody is joining a schedule instance or not.
I am going to write a script to migrate the default rules. Do we even have any at the moment?

[borgoat]

Yes we have many in the production database as I already synced the Firebase db in preparation of the old app migration.

Furthermore, keep in mind that due to the current setup I. Supabase the name of the table IS the API. Changing a table name is a breaking change, and in order to support existing clients a table must be created with the previous name. I never tested this though, so I'm not sure if all queries will work

[mforesti]

In that case, I see two options:

1. Keep the name of the table
2. Create a new table, which implies:
   • migration from old to new table
   • create a trigger on the old table that replicates any changes to the new table

I am kind of thinking to go for option 1. What do you think?

[borgoat]

In that case, I see two options:

1. Keep the name of the table
2. Create a new table, which implies:

I am kind of thinking to go for option 1. What do you think?

Keeping the name of the table is the easiest option. But if we keep the name of the table, then it doesn't make sense to start renaming other parts related to it, or we'll have an inconsistent codebase. And consistency is more important than good names.¹

Footnotes

1. https://stackoverflow.com/questions/1949364/should-i-keep-bad-naming-conventions ↩

[mforesti]

If consistency and care for the next developer are the principal arguments on the table for the above refactor, then it definitely makes sense to do the renaming.
I will write the migration and setup the trigger to replicate the old table to the new. Once we see that nobody is using the old version anymore, we can remove the old table.

[borgoat]

If consistency and care for the next developer are the principal arguments on the table for the above refactor, then it definitely makes sense to do the renaming. I will write the migration and setup the trigger to replicate the old table to the new. Once we see that nobody is using the old version anymore, we can remove the old table.

No: priority number 1 is users - not us.

[mforesti]

Exactly, I totally agree with you with the last statement!
The more consistent and maintainable the code is, the faster and easier it becomes to update the codebase and deliver value to users. Furthermore, the likelihood of bugs will decrease, though that's more of a philosophical discussion.