[MWPW-172587] Preflight check status #4496
Conversation
|
There was a problem hiding this comment.
There is no ASO, let's not write any code for something we don't have yet. Thinking ahead is good, but a project might get killed, stale, or implemented a year later.
It's usually not worth to thinking beyond your current use-case within a PR, so I'd suggest to remove everything related to ASO
@narcis-radu @robert-bogos Because we talked about it in our sync and the diagram, that there should be a "config type" to determain which Prefligh will be used and a "coverter" that would standardized the results. |
|
This pull request is not passing all required checks. Please see this discussion for information on how to get all checks passing. Inconsistent checks can be manually retried. If a test absolutely can not pass for a good reason, please add a comment with an explanation to the PR. |
There was a problem hiding this comment.
Let's also hear what Robert & Narcis have to say. But as an alternative, you could also raise the ASO specific implementation towards our ASO POC branch.
That way you can split this into "get the initial ticket & feature running"
and "make it compatible with the new feature (in it's own branch)"
... Having smaller PRs also makes this easier and more concise to review, focussing on the core bits of each PR:
- guide authors with page health checks
- create an ASO compatibility layer
|
overall thankyou for the review i'll go and change them @mokimo 👍 |
We had to think about abstracting the logic to allow known future use-cases, so it makes sense to have the "config type". However, at this point it doesn't make sense to actually handle the details, so let's remove the ASO logic. |
the im thinking of deleting the file and making things much simpler until we have ASO implemented. |
IMO, we only have to gain by gradually refactoring Preflight to accommodate ASO. It saves us time later, and while a case can be made that ASO might not happen, I think it’s clear by now that it will. Since there’s no immediate time pressure, we can advance now, unlike the possible tight deadlines when ASO integration becomes necessary. Also, since both Preflight and ASO are evolving in parallel, would help to build bridges (e.g., preflightExecutor.js) to keep them aligned. |
|
After further discussion, the best way forward seems to be keeping |
Now Preflight will be ran automatically when the page is loaded (once the
utils.jsis loaded).After Preflight is done running in the background, it will cache its results and when the User clicks on
tools>preflightto open up the Preflight Panel then the checks first look for already existing caches and if none were found they will then be ran manually.Also added a notification bar to inform the Athors of any failling checks, The Athors can click on the
reviewbutton to open up the Preflight Panel and get more details.Resolves: MWPW-172587
Test URLs: