| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
In the case of `dart fix`, the logic around apply/dryRun is all done in the client. The server computes a result and sends it back to the client, and the client either applies the edits or not. The server doesn't actually need to know whether the edits will be applied.
It's also the case that the display logic is all located in the client, so most of the verbiage is composed on the client side from the data returned by the server. I kind of like this split in responsibility, but I'll let you decide how you want to architect it.
field(If you decide to keep the apply/dryRun logic in the server, consider replacing this with a single field (maybe an enum or a bool) and minimally do the validation on the client side. It would have the benefit that if the user forgets to provide a flag they won't have to wait for a server to spin up before they can be told about the error.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |