Currently I'm using react and material-ui and I've the following code in my component.
<Dialog
title="Dialog With Actions"
actions={actions}
modal={false}
open={this.state.open}
onRequestClose={this.handleClose}>
Are you sure that you want to proceed?
</Dialog>
I've imported
import React from 'react';
import Dialog from 'material-ui/Dialog';
import FlatButton from 'material-ui/FlatButton';
But I'm always getting the following error message
Warning: Unknown prop `onKeyboardFocus` on <button> tag. Remove this prop from the element.
Warning: Unknown prop `keyboardFocused` on <button> tag. Remove this prop from the element.
Use react-tap-event-plugin to resolve this issue. After installing do this -
import injectTapEventPlugin from 'react-tap-event-plugin';
injectTapEventPlugin();
First, this is a warning and not an error message i.e. your code is still working. If you follow the link in the warning message, you can find out that:
The unknown-prop warning will fire if you attempt to render a DOM
element with a prop that is not recognized by React as a legal DOM
attribute/property. You should ensure that your DOM elements do not
have spurious props floating around.
There are more details and the possible reasons, but if I have to speculate you are passing all props to the button element.
Also interesting is a comment bellow the note:
For anyone who is curious/wondering why this new warning exists...
Historically, React has maintained a whitelist of all valid DOM
attributes, and we would strip unrecognized attributes. This approach
has a couple major downsides:
Performance: It means we must do a check for every prop on every DOM element, to sanity check that the prop is valid, and strip the
prop if it is not legal. This is silly, because the majority of
elements are completely safe (no illegal attributes) and thus the
checks are just wasted CPU cycles.
The old technique forced us to maintain a huge whitelist of all possible DOM attributes. This is a pain to maintain, but more
importantly, if we accidentally miss one or browser vendors add a new
one, it means that prop can't be used until we update our whitelist
The old technique is less flexible because it is impossible to render a non-standard attribute. While rendering non-standard
attributes is not recommended (you should use a data- attribute
instead), sometimes there are situations/frameworks that require
it. It sucks that React previously couldn't support it.
As we move toward removing this whitelist, we need to give people an
opportunity to clean up their existing apps. This way, an upgrade
doesn't result in us dumping a ton of unexpected props into the DOM.
EDIT:
Most probably this is coming from the jsx of the library you are using ( material-ui ) Check if you are using the latest version or if you are, they should probably address it soon
This is an issue with material-ui that they've already fixed. Wait for their 0.15.2 release or get their master branch now.
Related
On my site (written in React) I use a calendar so that the user can select a date and time range. For this I use the react-advanced-datetimerange-picker library.
Also in index.js file I use <React.StrictMode>. Because of this, when working with the library, I have some warnings. I would like to get rid of them.
I know the easiest way to remove <React.StrictMode>.
But this is not entirely true.
Below is a part of my code
return (
<DateTimeRangeContainer
ranges={ranges}
autoApply={true}
start={time.start}
end={time.end}
local={local}
applyCallback={handleDateRangeChange}
forceMobileMode
years={[2022, 2025]}
style={styleRange}
>
</DateTimeRangeContainer>
);
The whole problem lies in the DateTimeRangeContainer component. If I remove it, the warnings disappear. So here are the warnings I have:
react-dom.development.js:86 Warning: Legacy context API has been detected within a strict-mode tree. The old API will be supported in all 16.x releases, but applications using it should migrate to the new version. Please update the following components: FormControl. Learn more about this warning here: https://reactjs.org/link/legacy-context
and second..
react-dom.development.js:86 Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of DateTimeRangeContainer which is inside StrictMode. Instead, add a ref directly to the element you want to reference. Learn more about using refs safely here: https://reactjs.org/link/strict-mode-find-node
Help me fix them
The issue is most likely because of an older version of react used in the library. One workaround is to use another library or another one is to wait for the author to update the library.
I created an issue on the library repo. Please find it here
I'm trying to create my custom devtools for a high-level protocol renderer based on React now, so I'm learning how popular framework's devtools work, and I try to read the code of react-devtools and vue-devtools, have a basic understanding of how they work, but I still have a lot of questions:
Vue: I guess Vue set __vnode and __vueParentComponent as the dom Properties, and vue-devtools get Vue vm info by access dom properties.I don't read the code carefully, so I dont know how they pass the change of component tree, incremental update or full update, but I guess the __vnode is enough to rebuild the componentTree.
React: react-devtools is hard to read, I guess react send every change in react-reconciler, and rebuild the componentTree by these commits.I found there're some dom properties like __reactProps$... or __reactFiber$... in react, but I don't think they work in react-devtools.
preact: I dont read much code of it, I guess it just hook the class of Component and Fragment in Preact.
I‘m wondering which way is better to build my devtools, and It'll be very helpful If someone can give me more details or articles about these devtools
We have an established Vue/Nuxt app running in production, and for our latest sprint I implemented a bunch of pretty common changes we'd normally make for a new feature.
The changes did not include any structural changes to the primary page component or underlying layout component(s), rather the bulk of the changes were in an existing child component.
The page works perfectly fine in Chrome, Edge, Firefox, etc... usual story... but not in IE11.
I am unexpectedly receiving the following error upon page load;
[Vue warn]: Failed to mount component: template or render function not defined.
found in
---> <Anonymous>
<Nuxt>
<VApp>
<Layouts/default.vue> at layouts/default.vue
<Root>
The same page component works fine in other colleague's branches. So obviously it's 'one' of my changes but I just cannot identify anything component related. Especially given it works in other browsers.
For example, could this occur because of a unexpectedly needed polyfill that's not being loaded? I haven't used any ES5/ES6 features that we haven't used elsewhere - or on this page already - so it seems odd that would suddenly cause it.
Steps I've tried to debug;
Comment out the child component the bulk of my changes were in - no change
Replace EVERYTHING in the template block with `Hello World! - no change
Ensure an import exists for EVERY component within the failing page component (to ensure the Nuxt configured auto import isn't wigging out in IE - it's been working fine for months)
Killed the server and rebuilt the app multiple times just to be sure hot reload isn't being a problem
Hard re-cached the page in IE regularly just in case it's being a bleeeep and remembering something it shouldn't
Can confirm;
NO changes/updates have been made to packages
NO changes have been made to app configuration
NO changes to the folder location - thus route - the page component resides in
NO changes have been made to the underlying layout files (despite where the error message suggests the issue is)
As Vue developers know, often you'll see this generic error when you've messed up a component somewhere deep within your app that are completely unrelated to the layout component - and once fixed - this generic error goes away. Hence I commented out my child component to see if that was causing the issue.
I am vexed as to what might have changed to only break this page in IE11.
Apart from it being IE11 of course. Ugggh. I know. But we can't... yet :(
Any suggestions/help on what else I could test/debug would be greatly appreciated.
I figured out what was causing this, but it is a bit weird.
So clearly this was an issue inside a template, however nothing inside the scope of templates involved contained code that wasn't use elsewhere that was still working fine in IE11.
The template chain;
Default.vue (layout)
> pages
> {program}
> {form}
> _id.vue (this was the 'anonymous' template above)
> ServiceClaim.vue (shared component, changes were made here)
The process;
Commented ServiceClaim reference from _id.vue template - _id didn't render
Commented ServiceClaim import as well - _id rendered
Uncommented ServiceClaim - _id didn't render (definitely here, great)
In ServiceClaim component;
Commented all template markup - _id rendered
Commented all but previous claim list - _id rendered
Commented just the form markup - _id rendered
Issue is within the form...
Commented fields populated using .include ES6 function - _id didn't render
So it's a control with list items...
Commented fields retrieving list items - _id rendered
Confirmed...
Commented controls one by one until I found it was a radio group control
Refactored storage and retrieval of list items - no change
Added field-id attribute for consistency - no change
Change field-id and field-name attributes to use static values i.e. not using directive - _id rendered
Eureka!
Change field-id and field-name attributes to static values but using directive again - _id rendered
Curious
Change field-id and field-name attributes back to dynamic values using directive - _id rendered
Eh? But... ok fine
_id now renders in IE11 but effectively with the same code as before. Hmmmmm.
NB: I have since changed :row="true" to just row (used to be dynamically set hence the directive)
Conclusion;
To be fair I'm not entirely sure - perhaps someone else can explain but - this is ultimately a build issue that could not be rectified until the offending code was changed, restored, and the solution rebuilt.
I heard that strict mode helps to write React code in best practices way by throwing warnings for life cycle methods removal. I read about it from this article on Medium.
Is my understanding correct? How effective is strict mode? Is it only for unsafe life cycle methods? If not can I use this feature in functional components?
import { StrictMode } from "react";
class Test extends Component{
render(
<StrictMode>
//Some other child component which has all lifecycle methods implemented in it
</StrictMode>
);
}
React's StrictMode is sort of a helper component that will help you write better React components, you can wrap a set of components with <StrictMode /> and it'll basically:
Verify that the components inside are following some of the recommended practices and warn you if not in the console.
Verify the deprecated methods are not being used, and if they're used strict mode will warn you in the console.
Help you prevent some side effects by identifying potential risks.
As the documentation says, strict mode is development oriented so you don't need to worry about it impacting on your production build.
I've found it especially useful to implement strict mode when I'm working on new code bases and I want to see what kind of code/components I'm facing. Also if you're on bug hunting mode, sometimes it's a good idea to wrap with <StrictMode /> the components/blocks of code you think might be the source of the problem.
So yeah, you're in the correct path to understanding strict mode, keep it up, I think it's one of those things you understand better when you play with them, so go ahead and have some fun.
Warning: StrictMode will render the components twice only on the development
mode not production.
For instance, if you're using getDerivedStateFromProps method like so:
static getDerivedStateFromProps(nextProps, prevState){// it will call twice
if(prevState.name !== nextProps.name){
console.log(`PrevState: ${prevState.name} + nextProps: ${nextProps.name}`)
return { name: nextProps.name }
}
return {}
}
The getDerivedStateFromProps method will call twice.
Just to let you know this is not a problem, it's just because you're wrapping your main component with <StrictMode> in the index.js file.
StrictMode renders components twice in order to detect any problems with your code and warn you about them.
In short, StrictMode helps to identify unsafe, legacy, or deprecated APIs/lifecycles. It's used for highlighting possible problems. Since it's a developer tool, it runs only in development mode. It renders every component inside the web app twice in order to identify and detect any problems in the app and show warning messages.
StrictMode is a tool for highlighting potential problems in an application. Like Fragment, StrictMode does not render any visible UI. It activates additional checks and warnings for its descendants.
I am getting this error while working with react:
Warning: <Unknown Component /> is being rendered by both [Unknown] and [Unknown] using the same key (null) in the same place. Currently, this means that they don't preserve state. This behavior should be very rare so we're considering deprecating it. Please contact the React team and explain your use case so that we can take that into consideration.
Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op.
Here is some context about what we are doing:
We are building an application that dynamically adds and removes views from a container. These views are stored in a ViewStore. There are ViewActions to add and remove views.
All views that are managed in that store have a static ViewKey, which is uniquely used for this view. To add a view you can call ViewActions.addView(<SomeComponent />). If the view is already present, it will be replaced.
A ViewContainer renders these views by listening for changes from the ViewStore and renders the view with the key property set to the ViewKey.
When I add a view, which is already present, in reaction to a mouse-click event, everything is fine. When I add the exact same view from the developer console of chrome, and the view is already present, I am getting warnings mentioned above, but everything is working fine (probably, because the view has been rendered before).
How can I get rid of this warning?
EDIT: After some more investigation I found out, that this only happens, when firing the action from the Chrome Developer Console. In Firefox and IE (from the Developer Consoles) this works without problems.
Why do I only see this issue in Chrome?
when you add it with the developer console it will be an other type than a react component. you should see that if you shows the type with:
typeof <Component />
use that in the console and in the code. you should see a difference.