Refactor ASRouterAdmin to make it more extensible for the CMS Hackathon
Categories
(Firefox :: Messaging System, task, P1)
Tracking
()
People
(Reporter: aminomancer, Assigned: Mardak)
References
(Blocks 2 open bugs)
Details
Attachments
(6 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
I think the ASRouterAdmin component needs some refactoring in how it handles state. There is only one state container for the whole thing, which may become an issue. For example, I ran into an issue while adding the "Share" button. We want to show the "Share" button only for messages with a template supported by about:messagepreview. But template is part of the JSON message definition. It's something you can change in the editor. So what you really want is to check if the message's current template is valid. But you can't easily do that as the component is now, so you just have to use the initial message state as reported by ASRouter.
Ideally, we should have a component hierarchy like this:
ASRouterAdmin
GeneralView
MessagesList
ASRouter.state.messages.map(msg => <MessageItem initialValue={msg})
That way, each MessageItem can handle its own state, and rerender as expected when the textarea's value changes.
Breaking it down into individual components will also help us generally with making the CMS, as we will want to reuse portions or rearrange things, and that will be much easier if the components are separate components rather than class methods of a single global component.
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
Updated•2 years ago
|
| Reporter | ||
Comment 2•2 years ago
|
||
Comment 3•2 years ago
|
||
Comment 4•2 years ago
|
||
Comment 5•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 6•2 years ago
|
||
Depends on D193698
Comment 7•2 years ago
|
||
NI @dmosedale @mscott to help file next steps bug that will be using hackathon patches in to our first MVP
Comment 8•2 years ago
|
||
Lots of good stuff came out of this, and it’s definitely helpful in seeing some of the pieces clearly. A decision brief seems like a good structure for framing the next set of requirements and the architectural options for moving things forward, as well as a good artifact to discuss around. I’ve filed https://mozilla-hub.atlassian.net/browse/OMC-614 for this work.
I’ve linked to this bug, as I’m sure it’ll be invaluable as things are being thought through and code is being written.
This form is not currently planned to land in tree, so closing the bug.
Description
•