Skip to content
This repository has been archived by the owner on Sep 10, 2022. It is now read-only.

Remove useless optimisation #736

Merged
merged 1 commit into from
Aug 30, 2018
Merged

Remove useless optimisation #736

merged 1 commit into from
Aug 30, 2018

Conversation

istarkov
Copy link
Contributor

Removed optimisation is useless in React 16. The only intent for it was to not update if null was returned in handler.
But returning same value didn't caused update too, this is not same as React setState works.
This is possibly a breaking change.

@istarkov istarkov self-assigned this Aug 30, 2018
@istarkov
Copy link
Contributor Author

See realadvisor/rifm#27 (comment)

@istarkov istarkov merged commit 2b1741f into master Aug 30, 2018
@istarkov istarkov deleted the remove-optim branch August 30, 2018 09:52
goto-bus-stop pushed a commit to u-wave/react-server-list that referenced this pull request Aug 30, 2018

## Version **0.30.0** of **recompose** was just published.

<table>
  <tr>
    <th align=left>
      Dependency
    </th>
    <td>
      <a target=_blank href=https://github.com/acdlite/recompose>recompose</a>
    </td>
  </tr>
  <tr>
      <th align=left>
       Current Version
      </th>
      <td>
        0.29.0
      </td>
    </tr>
  <tr>
    <th align=left>
      Type
    </th>
    <td>
      dependency
    </td>
  </tr>
</table>



The version **0.30.0** is **not covered** by your **current version range**.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

It might be worth looking into these changes and trying to get this project onto the latest version of recompose.

If you have a solid test suite and good coverage, a passing build is a strong indicator that you can take advantage of these changes directly by merging the proposed change into your project. If the build fails or you don’t have such unconditional trust in your tests, this branch is a great starting point for you to work on the update.


---


<details>
<summary>Release Notes</summary>
<strong>withStateHandler behaviour change</strong>

<p>Remove useless in React 16 optimisation <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="355508627" data-permission-text="Issue title is private" data-url="acdlite/recompose#736" href="https://urls.greenkeeper.io/acdlite/recompose/pull/736#issue-212019167">#736 (comment)</a><br>
Make state change more similar to React setState.</p>
</details>


<details>
  <summary>FAQ and help</summary>

  There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html). If those don’t help, you can always [ask the humans behind Greenkeeper](https://github.com/greenkeeperio/greenkeeper/issues/new).
</details>

---


Your [Greenkeeper](https://greenkeeper.io) bot 🌴
goto-bus-stop pushed a commit to u-wave/web that referenced this pull request Aug 30, 2018

## Version **0.30.0** of **recompose** was just published.

<table>
  <tr>
    <th align=left>
      Dependency
    </th>
    <td>
      <a target=_blank href=https://github.com/acdlite/recompose>recompose</a>
    </td>
  </tr>
  <tr>
      <th align=left>
       Current Version
      </th>
      <td>
        0.29.0
      </td>
    </tr>
  <tr>
    <th align=left>
      Type
    </th>
    <td>
      dependency
    </td>
  </tr>
</table>



The version **0.30.0** is **not covered** by your **current version range**.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

It might be worth looking into these changes and trying to get this project onto the latest version of recompose.

If you have a solid test suite and good coverage, a passing build is a strong indicator that you can take advantage of these changes directly by merging the proposed change into your project. If the build fails or you don’t have such unconditional trust in your tests, this branch is a great starting point for you to work on the update.


---


<details>
<summary>Release Notes</summary>
<strong>withStateHandler behaviour change</strong>

<p>Remove useless in React 16 optimisation <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="355508627" data-permission-text="Issue title is private" data-url="acdlite/recompose#736" href="https://urls.greenkeeper.io/acdlite/recompose/pull/736#issue-212019167">#736 (comment)</a><br>
Make state change more similar to React setState.</p>
</details>


<details>
  <summary>FAQ and help</summary>

  There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html). If those don’t help, you can always [ask the humans behind Greenkeeper](https://github.com/greenkeeperio/greenkeeper/issues/new).
</details>

---


Your [Greenkeeper](https://greenkeeper.io) bot 🌴
@volkanunsal
Copy link

volkanunsal commented Oct 23, 2018

Hi! I started getting this error when I upgraded to version 0.30.0. I think this PR might be the culprit. Do you know how I can fix this error?

@istarkov
Copy link
Contributor Author

Just check your code, what causes setState on render. Usually this happens because of incorrect usage of setState, inside lifecycle handlers like componentDidUpdate, componetWillReceiveProps etc. Also this optimisation did nothing in modern (latest versions) of React.

@volkanunsal
Copy link

Hm, ok. I'm using React 16.4.0. I do use setState in componentWillReceiveProps, i.e. an updater from withStateHandlers, all over the place in my code. I didn't realize that was bad practice. Can you point me to where it says that?

Is there any harm in leaving this optimization in place given that some of us depend on its behavior?

@istarkov
Copy link
Contributor Author

istarkov commented Oct 23, 2018

Is there any harm in leaving this optimization in place given that some of us depend on its behavior?

No without example where will be shown that exactly removal of this optimisation caused the issue and the example code correct.

As componentWillReceiveProps is deprecated in React.
Also about bad practice - if you update state of the parent in cwrp depending on props it can cause infinite loop - its overall not good (but not so bad) practice to change state depending on props change. Here in issues there were few examples about. Same for cdu lifecycle having that it can cause loop changing its own state (not parent only)

@volkanunsal
Copy link

volkanunsal commented Oct 23, 2018 via email

@istarkov
Copy link
Contributor Author

This is the only major change since the last release. What else could it
be?

I'm more than 20 years in development, be sure I know the answer on "What else could it be".
And the answer is - IT COULD BE ANYTHING ;-)

@volkanunsal
Copy link

Come on now. You can't be serious.

@volkanunsal
Copy link

I'll take my time to test it more carefully, and maybe you're right.

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 this pull request may close these issues.

2 participants