Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat!: show expected and actual type for mismatches #1091

Merged
merged 2 commits into from
Nov 20, 2023

Conversation

brprice
Copy link
Contributor

@brprice brprice commented Nov 8, 2023

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.

@brprice
Copy link
Contributor Author

brprice commented Nov 8, 2023

EDIT: fixed

There is some bug with react flow and trying to show two flows in the "same place".

To see this, create a program with a mismatch; click the mismatch and see two types in the info (you will have to scroll); now click some other node and everything breaks weirdly.

(EDIT: actually, it is now broken even worse, where everything breaks pretty much immediately... NB: I have not tested this much at all, due to the brokenness...)

@brprice brprice changed the title (wip) feat: show expected and actual type for mismatches feat!: show expected and actual type for mismatches Nov 9, 2023
@brprice
Copy link
Contributor Author

brprice commented Nov 9, 2023

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)

@brprice brprice marked this pull request as ready for review November 14, 2023 16:17
@brprice brprice requested a review from a team November 14, 2023 16:17
@brprice brprice added the Deploy service Deploy the backend service for this PR label Nov 14, 2023
Copy link
Member

@dhess dhess left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@brprice
Copy link
Contributor Author

brprice commented Nov 14, 2023

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 <ben@hackworthltd.com>
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 <ben@hackworthltd.com>
@brprice
Copy link
Contributor Author

brprice commented Nov 20, 2023

I have bumped this to the latest backend version (which is merged to main).

@dhess
Copy link
Member

dhess commented Nov 20, 2023

Is this ready to merge, then?

@brprice
Copy link
Contributor Author

brprice commented Nov 20, 2023

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.

@dhess
Copy link
Member

dhess commented Nov 20, 2023

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.

@dhess dhess added this pull request to the merge queue Nov 20, 2023
Merged via the queue into main with commit b069437 Nov 20, 2023
24 of 26 checks passed
@dhess dhess deleted the brprice/nehole-type-info branch November 20, 2023 18:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Deploy service Deploy the backend service for this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants