Model: nilcars/facebook_react_model
Author: nilcars
Pipeline: text-classification
Library: setfit
Tags: setfit, safetensors, mpnet, sentence-transformers, text-classification, generated_from_setfit_trainer, arxiv:2209.11055, base_model:sentence-transformers/all-mpnet-base-v2, base_model:finetune:sentence-transformers/all-mpnet-base-v2, region:us
Base models (finetune): id: sentence-transformers/all-mpnet-base-v2
Card metadata: base_model: sentence-transformers/all-mpnet-base-v2
library_name: setfit
metrics: accuracy
pipeline_tag: text-classification
tags: setfit, sentence-transformers, text-classification, generated_from_setfit_trainer
widget: Bug: Radio button onChange not called in current React Canary <!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 18.3.0-canary-a1f97589f-20230526


## Steps To Reproduce

1. Create radio buttons that toggle `disabled` in `onChange`
2. After selecting each radio button, `onChange` is no longer called

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example:

The following CodeSandbox demonstrates the issue with the current react canary version. The issue is not present when react & react-dom versions are changed to stable 18.2.0

https://codesandbox.io/s/react-canary-radio-buttons-deiqb3?file=/src/App.js

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior
`<input type="radio" />`'s `onChange` prop is not called on subsequent clicks of the input

## The expected behavior
`<input type="radio" />`'s `onChange` prop should be called on subsequent clicks of the input
, Allow opting out of invokeGuardedCallbackDev At the moment, when in development mode, React uses a special workflow for callbacks, to avoid using `try...catch`.

It works well. So well that several testing frameworks also get their uncaught exception handling triggered.

**Example with mocha:**
```js
import React from 'react';
import { render } from '@testing-library/react';

function MyComponent({ doThrow }) {
    if (doThrow) { throw new Error('I'm bad'); }
    return <div></div>;
}

it('should throw', function () {
    expect(() => {
        render(<MyComponent doThrow/>);
    }).to.throw();
});
```
**Behavior:**
- When running the test with the production build of react/react-dom, the test passes (with the usual warning of act being unsupported in prod build).
- When running the test with the development build of react-/react-dom, the test fails with `Error: Uncaught Error: I'm bad`.

The root cause is `invokeGuardedCallbackDev` runs the callback in an event to avoid using a `try...catch` block… and trips Mocha.js uncaught exception detector.

*Note: I am aware of error boundaries, I removed it from the example because the behavior is identical with it.*

*Note: I used testing-library for clarity, but using `act` and `RenderDOM` manually yields the same result.*

**Expected behavior:**
- Either make it work out of the box, or have the possibility to opt out of `invokeGuardedCallbackDev` and force the use of the regular `try...catch` implementation in development too.
, Setting rendering mode to <Surface> component of react-art <!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
feature

**What is the current behavior?**
`<Surface>` of canvas mode and `<Surface>` of svg mode cannot be used in a document at the same time.

**What is the expected behavior?**
Two more `<Surface>` components with each other modes can be used in a document at the same time.


Currently developers can set only one rending mode globally in react-art, using `setCurrent()` of `art/modes/current` module. So there is no way to use `<Surface>` of canvas mode and `<Surface>` of svg mode in a document together. On the other hand, `art.js` internally used in `react-art` provides a way to use each other modes together as directly importing their corresponding modules.  (e.g. svg.js for svg mode, canvas.js for canvas mode in `art.js` lib). 

I would like to suggest a way to set own rendering mode per instance of `<Surface>` Component by new property `mode`. This feature makes `<Surface>` with canvas mode and `<Surface>` with svg mode to be used together in a document like the following.

```javascript
const {
  Surface,
  Group,
  Shape
} = require('react-art');

class TestComponent extends React.Component {
  render() {
    return (
      <React.Fragment>
        <Surface mode="svg" width={100} height={100}>
          <Group>
            <Shape width={10} height={10} />
          </Group>
        </Surface>
        <Surface mode="canvas" width={100} height={100}>
          <Group>
            <Shape width={10} height={10} />
          </Group>
        </Surface>
      </React.Fragment>
    );
  }
};
```

If `mode` property is not set, `<Surface>` works as canvas mode for compatibility.

I have made a PR for this feature to show how to work and use it ([#13249](https://github.com/facebook/react/pull/13249)).
And you can check this feature through `art` fixture of my PR.

Feel free to discuss about this feature.



, [DevTools Bug]: Firefox and Edge show error in console about unrecognized installation on v4.20.0 ### Website or app

reactjs.org

### Repro steps

1. Install React DevTools v4.20.0 in Firefox
2. Load reactjs.org in Firefox
3. Open Firefox DevTools
4. Observe error in console

![image](https://user-images.githubusercontent.com/1271509/137547605-e6ad3045-c20a-4828-9895-af46b8bb4db1.png)


### How often does this bug happen?

Every time
, componentWillUpdate discussion <!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

Feature : componentWillUpdate Discussion

**What is the current behavior?**

The current behavior calls the function before re-rendering the render target however there is no indication for when the re-render method should be called

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

**What is the expected behavior?**

The expected behavior should call the function before re-rendering the render target if there is no returned conditional statement and if there is, true should trigger the re-render and false should not

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

16.4.0

I have a few questions before I try to solve this problem and it gets rejected. I'm assuming that the team has decided to move in the direction of removing "Will-Updates" from React all together and have labeled them "Unsafe". I've seen a lot of issues with those functionalities before as well. I was curious if providing a conditional statement inside those functions would satisfy the unexpected renders. "shouldComponentUpdate" does trigger when to call these functions however in those functions that "will" run before the render can always be controlled with a conditional statement of it's own. I'm getting comfortable with the code base however I'm curious if the team is removing that functionality all together and using the "static" function "getDerivedStateFromProps" instead. Has a React lover it is a little confusing and may break a lot of legacy code when updating versions. I believe that may solve the problem of unexpected renders after a "will" change lifecycle event.

I was curious if that was the case, and removing "will" lifecycles is the next steps for React then how will the "did" lifecycles work instead?

I love React and I'm just curious about the future for React as a whole. I'd love to tackle any bugs or feature requests when I have time. I will be writing clean code and create tests for new features or bugs as well.
inference: yes
Likes: 0 | All-time downloads: 116
Created: 2024-06-24 10:07:31