feat!: show expected and actual type for mismatches #1091
Conversation
|
EDIT: fixed
|
brprice
force-pushed
the
brprice/nehole-type-info
branch
from
c53fac9
to
c331701
Compare
brprice
changed the title
|
Note that the backend PR is hackworthltd/primer#1172, which is not quite ready to merge currently, however (other than bumping the backend pin further in the first commit here), I do not expect to need any more frontend changes. Having said that, this is obviously not good UI (in particular, the "floating infobox" is too small to nicely contain two trees, and one needs to scroll inside it to see the lower one) |
There was a problem hiding this comment.
Thanks! It's getting a bit cramped in the type info window when there's a misfit, but it's all going to be redesigned soon anyway, so this gets the job done until that happens.
After a bit of testing, there is one weird little quirk where the Expected Type isn't properly centered in its subview the first time you select a misfit, but it seems to go away upon subsequent selections. Per paragraph above, since this will all be restyled soon anyway, let's just leave it.
Huh, odd. I have no idea why or how that happens. I'm happy to leave it for now. |
When selecting a non-empty hole, the API now emits information about both the expected and actual types. We adapt to this change by ignoring the actual type and just displaying the expected one (this matches the behaviour with the old backend version). In a subsequent commit we will show both. BREAKING CHANGE: the API is different from the previous backend pin. Thus this version of the frontend cannot talk to the previous version of the backend and vice versa. Signed-off-by: Ben Price <[email protected]>
Mismatches, aka non-empty holes, now show both relevant types. Previously one would see the expected type in the "Selection info" of the hole, and the actual type in the info of the body of the hole. Now one sees both in the info of the hole. Signed-off-by: Ben Price <[email protected]>
brprice
force-pushed
the
brprice/nehole-type-info
branch
from
a08f3dc
to
8edaea6
Compare
|
I have bumped this to the latest backend version (which is merged to main). |
|
Is this ready to merge, then? |
Other than the storybook diff. It seems there are subtle changes in one of the avatars, and I don't understand why. Feel free to merge if you think this is not a worry, otherwise I could investigate. |
|
Hmm, that's odd, but I'm not concerned about it. We don't properly keep Chromatic's baselines up-to-date, so it might be due to unrelated changes in dependencies. |
Mismatches, aka non-empty holes, now show both relevant types. Previously one would see the expected type in the "Selection info" of the hole, and the actual type in the info of the body of the hole. Now one sees both in the info of the hole.
BREAKING CHANGE: the API is different from the previous backend pin. Thus this version of the frontend cannot talk to the previous version of the backend and vice versa.