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

Reactivity breaks in large components after updating to 3.19.1 #4515

Closed
arggh opened this issue Mar 6, 2020 · 1 comment
Closed

Reactivity breaks in large components after updating to 3.19.1 #4515

arggh opened this issue Mar 6, 2020 · 1 comment

Comments

@arggh
Copy link
Contributor

arggh commented Mar 6, 2020

Describe the bug

After upgrading from 3.7.1 to 3.19.1, I noticed one of my views lost reactivity in some parts. Trying to figure out why was driving me insane. A simple reassignment, like this (as part of a larger component):

<script>
  function assign(ri) {
    console.log('This statement gets logged, but the view doesn't reflect the data');
    renderItems = ri;
  }
</script>

<Grid {renderItems} let:item>
  <GridItem {item} />
</Grid>

...would not update the <GridItem>s, when renderItems changed.

Reverting back to 3.7.1 was ean easy fix, and although I think it's the best and most bug-free release of Svelte ever, I'd prefer not to be stuck with it forever.

Finally, after hours of debugging, I managed to "work around the bug".

The solution?

Just remove random code from the view component. It's a large component, ~260 LOC without styles, and if I remove a few blocks of template code (completely irrelevant of the <Grid> part), then reactivity inside the <Grid> starts working again.

I could even bring the view to a state where I had this code:

{#if something}
  <Test
    onPrevClicked={() => setNextEditItem(-1)}
    onNextClicked={() => setNextEditItem(1)}
  />
{/if}

...and the reactivity inside <Grid> stopped working. If I removed the second prop, onNextClicked, it started working again. <Test> was just an empty file with nothing inside, besides an empty <script> block.

Now, the only explanation that I can think of, comes from worries expressed by @Rich-Harris at some point when introducing bitmask change tracking:

it places a constraint on components: you can only reference 53 separate top-level variables

...and later in #3945

need to figure out how to handle components with more than 31 changeable top-level values

Like I said above, my view component is large, and the only remedy seems to be deleting random code. I suspect there might be something still broken in the bitmask change tracking.

Logs
There is no logs, as no errors are thrown. Changes just no longer propagate.

Information about your Svelte project:

  • Your browser and the version: All the browsers

  • Your operating system: Mac OS Mojave

  • Svelte version: 3.19.1

Severity
Updating to latest Svelte completely breaks existing code that used to work. I'm really worried where else it might have broken things that aren't as apparent.

@arggh
Copy link
Contributor Author

arggh commented Mar 6, 2020

.....aaaaaand I noticed 3.19.2 was just released with a bugfix titled "Fix bitmask overflow for slots". Sounds about right? Yes, it fixes the problem.

Thank you @cdhanna for noticing this in #4481 before I did .

I noticed my slot-prop changes weren't getting picked up in the parent component, and it drove me nuts for almost a whole day. Eventually, as I started removing bits and bits of code to isolate the problem, it started working again. Finally, it got to the point where it worked, until I added an unused top level variable. As I was looking around, I came across this merged feature in 3.16 #3945 . I haven't read the PR in full, but from skimming it, my gut tells me its related to my bug.

...I can relate. I lost a day of my life to this bug as well. I find it amusing though, how the two of us, completely unknown to each other, kind of shared a timeline while debugging this, stars aligning and all that, arriving at the same conclusion:

my gut tells me it's related to #3945 😅

@arggh arggh closed this as completed Mar 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant