firefox-devtools / firefox-devtools/profiler
Reduce special-casing of markers based on data.type
- Dominant language
- TypeScript
- Stars
- 1.5k
- Forks
- 491
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 30
Description
We have a lot of places in the code where we treat a marker in a special way because of its `data.type`. We also have a marker payload type enum which discriminates based on `type`. For example, [this code](https://github.com/firefox-devtools/profiler/blob/faaf1a14affd3c6d8b7342188371079b999abf5b/src/profile-logic/marker-schema.ts#L301) can access `data.operation` without checking for the presence of the `operation` field because it has already checked that `data.type === 'FileIO'` so the `data.type` type was refined to [`FileIoPayload`](https://github.com/firefox-devtools/profiler/blob/faaf1a14affd3c6d8b7342188371079b999abf5b/src/types/markers.ts#L594-L608) which guarantees the presence of the `operation` field.
If we want to remove `data.type` to save space (#4494), we'll run into trouble with the type checker.
We could keep the special cases and add enough "is this field present and of the right type" checks to make the type system happy. Or we could have some "as any" escape hatches.
But overall it would be nicer if we made use of marker schemas more and didn't assume that certain fields are present just because the schema has a certain name.
So I think it would be better if we reduced the number of places with special marker handling.
Here's a catalogue of places where we have these special marker assumptions: [special-marker-handling.md](https://gist.github.com/mstange/d312cfd564c6d8dfdc1426a540442cc3#file-special-marker-handling-md)
┆Issue is synchronized with this [Jira Task](https://mozilla-hub.atlassian.net/browse/FP-1372)
Contributor guide
Assessment
This issue has not been assessed yet.