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

deploying to Vercel causes conditional statements to evaluate incorrectly #16542

Closed
AHBruns opened this issue Aug 25, 2020 · 13 comments · Fixed by #17081
Closed

deploying to Vercel causes conditional statements to evaluate incorrectly #16542

AHBruns opened this issue Aug 25, 2020 · 13 comments · Fixed by #17081
Assignees
Milestone

Comments

@AHBruns
Copy link

AHBruns commented Aug 25, 2020

Bug report

Describe the bug

When rendering a page using Incremental Static Regeneration a *conditional statement is erroneously applied to the wrong element.

*I'm referring to conditional rendering expressions of the following form:

<div>
   {true && <div />}
   <div />
</div>

To Reproduce

  1. go to my repo, https://github.com/AHBruns/vercel-repro
  2. clone it, npm install, and *npm run dev
  3. inspect element
  4. you'll see the following, which is correct:
<div>
   <div class="SHOW"></div>
</div>
  1. deploy the repo to Vercel
  2. go to the deployed site
  3. inspect element
  4. you'll see the following, which is incorrect:
<div>
   <div class="NO_SHOW"></div>
</div>

*npm run build && npm run start yields the same problem

Expected behavior

A single div with the class SHOW should be added to the DOM regardless of the environment.

System information

  • Version of Next.js: v9.5.2
  • Version of Node.js: v14.3.0
@AHBruns AHBruns changed the title Deploying to Vercel causes app to run incorrectly Deploying to Vercel causes conditional statements to evaluate incorrectly Aug 25, 2020
@AHBruns AHBruns changed the title Deploying to Vercel causes conditional statements to evaluate incorrectly [BUG]: deploying to Vercel causes conditional statements to evaluate incorrectly Aug 25, 2020
@AHBruns AHBruns changed the title [BUG]: deploying to Vercel causes conditional statements to evaluate incorrectly deploying to Vercel causes conditional statements to evaluate incorrectly Aug 25, 2020
@Timer
Copy link
Member

Timer commented Aug 25, 2020

Could you please upgrade to next@canary and try this again? We've fixed a lot of CSS-related things in the newest canary.

@Timer Timer added the please add a complete reproduction The issue lacks information for further investigation label Aug 25, 2020
@AHBruns
Copy link
Author

AHBruns commented Aug 25, 2020

Could you please upgrade to next@canary and try this again? We've fixed a lot of CSS-related things in the newest canary.

Okay. Just did this, and the problem persists.

@AHBruns
Copy link
Author

AHBruns commented Aug 25, 2020

I should add that this isn't really CSS related. It seems like the conditional statement is being applied to the wrong element somehow. The CSS was just to illustrate that.

@Timer Timer added kind: bug and removed please add a complete reproduction The issue lacks information for further investigation labels Aug 25, 2020
@Timer Timer added this to the iteration 8 milestone Aug 25, 2020
@Timer
Copy link
Member

Timer commented Aug 25, 2020

Thanks, we'll take a peek soon!

@AHBruns
Copy link
Author

AHBruns commented Aug 25, 2020

My original example had a lot going on. I made a clean new repo and was able to build up to triggering the bug.

reproduction repo

It seems to be related to rendering pages that use Incremental Static Regeneration. I still can't identify why the conditional is being applied to the wrong element because it's a completely silent error (AFAIK even if the boolean was flipped the result I'm getting from Vercel would still be impossible).

Interestingly, the only valid evaluations of the following code

image

are:

<div>
   <div class="SHOW"></div>
</div>

or

<div>
   <div class="NO_SHOW"></div>
   <div class="SHOW"></div>
</div>

However, the Vercel page is the following:

image

which should be impossible. Hence, this probably has to be a problem in either how Vercel transpiles my code or how the browser interprets the transpiled code. Because I've tested a couple different browsers and found the same problem across all of them, it seems to me that Vercel's transpiler likely has a bug.

@AHBruns
Copy link
Author

AHBruns commented Aug 25, 2020

My original example had a lot going on. I made a clean new repo and was able to build up to triggering the bug.

reproduction repo

It seems to be related to rendering pages that use Incremental Static Regeneration. I still can't identify why the conditional is being applied to the wrong element because it's a completely silent error (AFAIK even if the boolean was flipped the result I'm getting from Vercel would still be impossible).

Interestingly, the only valid evaluations of the following code

image

are:

<div>
   <div class="SHOW"></div>
</div>

or

<div>
   <div class="NO_SHOW"></div>
   <div class="SHOW"></div>
</div>

However, the Vercel page is the following:

image

which should be impossible. Hence, this probably has to be a problem in either how Vercel transpiles my code or how the browser interprets the transpiled code. Because I've tested a couple different browsers and found the same problem across all of them, it seems to me that Vercel's transpiler likely has a bug.

Rewrote the bug report to reference this reproduction.

@timneutkens
Copy link
Member

Did some investigating:

  • Added a next.config.js with target: 'experimental-serverless-trace'
  • Ran next build
  • The console.log in _app logged out /404 which is unexpected

So this is definitely a bug in Next.js, we'll fix it 🙏

@AHBruns
Copy link
Author

AHBruns commented Aug 25, 2020

Did some investigating:

  • Added a next.config.js with target: 'experimental-serverless-trace'

  • Ran next build

  • The console.log in _app logged out /404 which is unexpected

So this is definitely a bug in Next.js, we'll fix it 🙏

Sounds good. Thank you for the quick response!

@Timer Timer modified the milestones: iteration 8, iteration 9 Sep 8, 2020
@Timer Timer added the point: 3 label Sep 10, 2020
@kodiakhq kodiakhq bot closed this as completed in #17081 Sep 14, 2020
kodiakhq bot pushed a commit that referenced this issue Sep 14, 2020
This normalizes the `asPath` for `getServerSideProps` and `getStaticProps` pages to ensure it matches the value that would show on the client instead of a) the output pathname when revalidating or generating a fallback or b) the `_next/data` URL on client transition. 

Fixes: #16542
@ijjk
Copy link
Member

ijjk commented Sep 14, 2020

Hi, this should be fixed in v9.5.4-canary.16 of Next.js please upgrade and give it a try!

@AHBruns
Copy link
Author

AHBruns commented Sep 14, 2020

Thanks a million! I'll confirm everything is fixed when I get home evening.

HitoriSensei pushed a commit to HitoriSensei/next.js that referenced this issue Sep 26, 2020
This normalizes the `asPath` for `getServerSideProps` and `getStaticProps` pages to ensure it matches the value that would show on the client instead of a) the output pathname when revalidating or generating a fallback or b) the `_next/data` URL on client transition. 

Fixes: vercel#16542
@vikasg603
Copy link

Hey, i am using "next": "^10.0.7"
I am getting the same issue with my conditional rendering code.

Is there any way to resolve this?

@vikasg603
Copy link

It's just that I am getting this issue in dev mode, and only if I am refreshing the page or either going to that page directly.
There is no issue if I am going on that particular page from another page.

@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants