refactor: deprecate old ConstraintAccordion and point to new version #9613
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files |
thomasheartman
left a comment
thomasheartman
left a comment
There was a problem hiding this comment.
Wouldn't the right thing here be to move it into a "LegacyConstraintAccordion" folder? And I'm not sure I understand the linear ticket:
There is a new one, since before this project. Old one is used only on segments.
Are you saying that even before the project, there was a different constraint accordion in use somewhere? What happened to it; have we replaced it in this project? So now we have three? (this one, the other old one, and the new one?)
|
Yes, before current project there where 2 constraint accordion copies in use. We still have 2. Old one is used in segments, but helper functions from it are used in many other places unfortunately. For flag facelift we rebuilt things in a newer version. |
github-project-automation
bot
moved this from In Progress
to Approved PRs
in Issues and PRs
|
Great! Do we have a path forward for removing this component completely? Or is it too tangled up for now? |
Best time to handle it will be if(/when?) we refactor Segments-Edit page. |
About the changes
Code for constraint accordion was copy-pasted before previous improvement. Old version is still in use for Segments. When we get to improving constraint editing we should rebuild segments editing, without use of this code.
Internal ticket: issue/1-3536