During estimation we discussed that Pixel seems to cover most of the things we got out of storybook so we may want to remove it and update Pixel tests to capture it.

Jon to separate out the Popups upgrade into a separate ticket.

Change 1010968 had a related patch set uploaded (by Mabualruz; author: Mabualruz):

[mediawiki/extensions/MobileFrontend@master] Remove MobileFrontend storybook

https://gerrit.wikimedia.org/r/1010968

In T354974#9507301, @Jdlrobson wrote:

During estimation we discussed that Pixel seems to cover most of the things we got out of storybook so we may want to remove it and update Pixel tests to capture it.

Jon to separate out the Popups upgrade into a separate ticket.

I have added the patch to remove the story book files and configuration. still If anything needed to be added to pixel, we have to point them out or put it as an expected outcome of this ticket

Change 1010968 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Remove MobileFrontend storybook

https://gerrit.wikimedia.org/r/1010968

Sign Off/Next Steps:

• Talk about this more
• Write a ticket about making an ADR in the repo about storybook's future

To summarise the discussion from Slack that is mostly provided by @Jdlrobson, here are the key points:

• MediaWiki's lack of hot reloading: Noted as particularly useful during development for instant feedback, but absent in MediaWiki's workflow. The workaround involves using Storybook to observe changes in components during development.
• Coverage by Pixel: Pixel is recognised for its comprehensive coverage of important aspects. However, gaps are acknowledged in replicating the block workflow, which presents challenges due to its complexity and because it's controlled by other teams.
• Debate on the need for a Storybook-like tool: There's a consensus that reintroducing something akin to Storybook might not be necessary for components managed by other teams, especially for specific, complex aspects like the block workflow.
• Push for Codex integration: Emphasised as a way to reduce the reliance on Storybook by moving more components and functionalities to Codex, thereby simplifying the development process.
• Visibility of custom components: The inability to easily overview custom components, as is possible with Codex, is flagged as a concern, indicating a need for better management or integration strategies for these components.
• Future plans: The discussion hints at the drafting of an Architecture Decision Record (ADR) and scheduling a Software & Hardware Design Team (SHDT) meeting to further address these topics.
• Mobile frontend and Pixel coverage: The initial thread emphasises the need to increase Pixel mobile coverage for cases previously addressed by Storybook. This aims to identify and address gaps in Pixel's coverage, potentially leading to an ADR ticket for comprehensive documentation and action planning.
• Next steps: Arranging the ADR and SHDT meeting, will be coordinated by @Jdrewniak.