Distributed computation caching and task execution are currently disabled for this organization. Loading workspace insights... Statistics interval
7 days30 daysLatest CI Pipeline Executions
4c53565a Added email design customization to automations (#28004)
closes
https://linear.app/ghost/issue/NY-1252/move-email-design-customization-modal-from-settings-to-automations
I highly recommend reviewing this
[commit-by-commit](https://github.com/TryGhost/Ghost/pull/28004/commits).
I've isolated the "copy all the files from settings app" commit so you
don't have to review every line of the existing code, and can focus on
the net-new changes in this branch.
## Summary
- Refactored the Settings welcome email design data flow so lower-level
modal helpers receive explicit data instead of reading global settings
context
- Copied the refactored Welcome emails design modal into the Automations
area as a separate commit for easier review
- Adapted the copied modal for Automations ownership and added an Email
design action to the Automations list page while keeping the Settings
entry point intact
## This is a lot of duplication!
Yes, yes it is. The problem is that we currently need to support the
same email design modal in the settings app _and_ the posts app. We
don't have any existing patterns for this, at least not that I could
find. I think duplicating the whole thing is the least-worst option,
given that:
- it's temporary - we'll remove the modal from settings once Automations
GAs
- it's simpler, at least in terms of the dependency graph, than trying
to import the modal from settings into posts
- it works - I tried a few other approaches (i.e. importing directly
from settings), but I simply could not get them to work
### Other options considered
- Import the modal components from settings. This works and has less
duplication. My only real argument against this is that it's weird and
IMO more complex, despite requiring far fewer lines of code.
- Add the modal to admin-x-framework or shade. This would work and
eliminate the duplication, but it feels bad including code that is
closely coupled with automations in a "framework" or "design system"
- Add a new apps/* app for shared UI code like this. Arguably more
correct, but new apps aren't free and this feels heavy handed for this
one-off use-case
---------
Co-authored-by: Troy Ciesco <tmciesco@gmail.com>