I don't understand this warning in my console. Can someone tell me if it's library's problem or if it's an error in my side ?
Warning image
Here is my code which trigger the warning
I'm using the version 13.1.1
<DragDropContext onDragEnd={handleDrop}>
<Droppable droppableId="list-container" >
{(providedA: any) => (
<div {...providedA.droppableProps} ref={providedA.innerRef}>
{steps.map((step, index) => {
return <Draggable key={step.id} draggableId={step.id.toString()} index={index}>
{(provided: any) => (
<div ref={provided.innerRef} {...provided.dragHandleProps} {...provided.draggableProps}>
<div>{step.title}</div>
</div>
)}
</Draggable>
})}
{providedA.placeholder}
</div>
)}
</Droppable>
</DragDropContext>
Thanks
I tried to remove the code to find that is the Droppable element which cause the issue. I don't find on the github of React-beautiful-dnd any question on this.
The warning is caused by the library. Specifically, react-beautiful-dnd uses an old version of react-redux, which in turn uses the feature mentioned in the message: defaultProps.
So normally, react-beautiful-dnd would update it's code to use a new version of react-redux, and then you would update to their latest and the problem would go away. However, since react-beautiful-dnd is no longer being developed, it is unlikely that they will do that. This leaves you with a couple options:
The code still works, so you could just do nothing. React is warning you that defaultProps will eventually stop working, but we're not there yet. The earliest possible release that could break the code is react 19.0.0, but there isn't even a timeline for that release yet.
You could switch to a different library than react-beautiful-dnd. Maybe something like react-draggable would work for you, though i don't know what your needs are
You could fork react-beautiful-dnd and modify their code to fix it. Then you'd use the forked version of the code instead of the original.
Related
So I'm making a calculator, it takes a string, makes an equation, and computers it as you type. Modelled after an app called Soulver.
Live: https://chartley1988.github.io/chartleys-calculator/
Github: https://github.com/chartley1988/chartleys-calculator
This is the part of a react element where it's called:
return (
<TextareaAutosize
aria-label='textInput'
className='editor-input-line'
id={`input-${lineNumber}`}
type='text'
onChange={onChange}
data-testid="testEditorLine"
></TextareaAutosize>
);
It calls a function (which is too long to post) in a parent component. It seems to work perfectly in chrome, but not at all in Safari. What's the best work around for this?
I've tried using an addListener for onChange, instead of directly calling it from Component return. But this seems to only update the answer when focus is removed from the input. And doesn't fix the safari problem. I could maybe just update on any key presses, but with many lines of calculations I feel like this would lead to bad performance.
Try use:
return (
<TextareaAutosize
aria-label='textInput'
className='editor-input-line'
id={`input-${lineNumber}`}
type='text'
onChange={() => onChange()}
data-testid="testEditorLine"
></TextareaAutosize>
);
This has been solved. It ended up being an issue with Regex, NOT onChange as previously thought. Safari does not support lookbehind regex's, which was causing the error. Thanks!
For now, I am not using any other styling or .css files on my page. The Alert's width extends to the whole page. I am trying this but it doesn't make any difference:
function StatusMessage(){
if (isRemoved){
return (
<Alert style={{
width:'50%',
}}
className='alerts' severity="success"> User Removed</Alert>
)
}
}
Can't reproduce, just threw into my React project and style={{width:'50%'}} works.
Ideas for debugging:
remove redundant className='alerts', that as well may mess it up when yourself or some library by accident defines CSS on such class.
report within what container it resides: block, flex-box and others behave differently, although I tested on first two and both worked fine for me.
Use browser debugger and report what CSS rules actually applied or were overruled to the element that may give more insights to help you.
I an encountering an issue with react-dropzone for quite a long time.
First, let's jump straight to the problem with a video: https://drive.google.com/open?id=1UmWtHbQ9U0LBHxYtZ1YSoXrfsezwH-os
The file choser window opens twice on every file inputs of my website, it is not an infinite loop, just twice.
Here is the code I use for this dropzone:
<Dropzone onDrop={this.onDrop.bind(this)}
key={this.state.key}
style={{border: "none"}}>
<div className="input-file">
<label for="file">
<button type="button">Choisissez un fichier</button>
</label>
</div>
<div className={"file-name " + (!this.state.selectedOption ? '' : 'hidden')}>
Aucun fichier choisi
</div>
<div className={"file-name " + (this.state.selectedOption ? '' : 'hidden')}>
{this.state.selectedOption}
</div>
</Dropzone>
The unwanted event happens every time I drop or even when I click on the input itself
If hope to give you guys enough information, if you need more I will more than happy to share code.
Just stumbled upon this too, in my case this was related to Dropzone being wrapped in a label. label passes clicks to descendant inputs.
As a workaround, you can remove the parent label (or change it to div or whatever).
Or, although I do not recommend it, monkey-patch Dropzone.prototype.onInputElementClick (or subclass and override). No further instructions here, as to not facilitate people shooting their feet.
Related react-dropzone issue: https://github.com/react-dropzone/react-dropzone/issues/182.
Faced the same issue, later found a way to solve it. Just add stopPropagation to parent div onClick.
This issue has been resolved in react-dropzone version 10.1.3.
I had the problem with version 10.1.0. Once I upgraded it to v10.1.3 in package.json, the problem is gone.
"dependencies": {
"react-dropzone": "^10.1.3"
}
I get the following warning when rendering my component:
Warning: A component is contentEditable and contains children
managed by React. It is now your responsibility to guarantee that none
of those nodes are unexpectedly modified or duplicated. This is
probably not intentional.
This is my component:
import React, { Component } from "react";
export default class Editable extends Component {
render() {
return (
<div contentEditable={true} onBlur={this.props.handleBlur}>
{this.props.children}
</div>
);
}
}
What is the potential problem with my code that React wants to warn me about? I did not quite understand from reading the documentation at https://reactjs.org/docs/dom-elements.html.
I imagine that my component should work exactly like an managed input field, without any problem:
this.props.children is initial value
the onBlur callback updates the props from event.target.innerHTML
the component is rendered with the new props
Setting the contenteditable html attribute allows the contents of that element to be modified in the browser. React is warning you that you have children within that element that are managed by React. React only works from the top down. Meaning it manages a model at the top level and maintains a virtual DOM representing that data, then renders the DOM tree based on that virtual DOM. Any changes you make to the DOM outside of React (such as setting contenteditable and allowing the content to be edited by a user directly in the browser) will be potentially blown away or cause problems for React when it goes to update those managed elements.
In your situation you don't care that the {this.props.children} node gets blown away because you know you're catching the changes and doing what you need to with it. It's just warning you that you better not expect that node to remain intact and accurately updated by React when you're letting the content be edited by the browser directly.
If you know what you're doing (and for now it looks like you do) then you can suppress that warning by adding suppressContentEditableWarning={true}.
Thanks #Chev! It fixed the warnings..
<p
className={editing ? 'editing' : ''}
onClick={editOnClick ? this.toggleEdit : undefined}
contentEditable={editing}
ref={(domNode) => {
this.domElm = domNode;
}}
onBlur={this.save}
onKeyDown={this.handleKeyDown}
{...this.props}
suppressContentEditableWarning={true}
>
{this.props.value}
</p>
I use material-ui components in react with react-router. I have a problem when I want to display list-items that are supposed to work as link elements, but also contain a submenu inside that should not trigger the parent link. It does and I don't know how to disable it.
var iconMenu =
<IconMenu iconButtonElement={<IconButton><MoreVertIcon /></IconButton>}>
<MenuItem primaryText='change name' onTouchTap={this.edit}/>
<MenuItem primaryText='delete' onTouchTap={this.delete} />
</IconMenu>
<ListItem
key={i}
containerElement={<Link to={`/items/${item.id}`} />}
rightIconButton={iconMenu}
/>
When I click the iconMenu button, I do not want the <Link to={`/items/${item.id}`} /> to be triggered, so that I stay in the page. But it does. So how can I fix this problem? I tried to add event handler to run stopPropagation() but it was not successful...
Thanks!
For React Router v4, add
onTouchTap={() => this.props.history.push(`/items/${item.id}`)}
to the ListItem, instead of containerElement.
Use import { withRouter } from 'react-router-dom' and export default withRouter(Foo) to add history to the component's props.
First of all, I'd like to admit that I do not like material-ui and thus do not recommend it to people who consider starting a project with it. The reasoning behind is that you sacrifice too much time customising the components to your needs - a solution that is opposite to the idea of React. It also uses inline styles that you always have to overwrite in the component file, not in your scss or less. This sucks big time. I don't even mention all the UI interaction actions that are handled with JS that could make your performance ache.
Another short mention is to the react-router. Unfortunately I'm not a fan of it either. Guys, why do you change the API in every next release? Why is it so damn difficult to just reset the location queries? Just look at FlowRouter and see how fantastic a route API should be implemented.
Anyways, my solution was to implement a wrapper around the <Link /> component and move the <IconMenu /> outside of the <Link /> wrapper:
<li key={i}>
<ListItem
key={i}
containerElement={<Link to={`/items/${item.id}`} />}
/>
{iconMenu}
</li>