Comments (6)
hey! the library is supposed to only be used in dev.
the code
if (process.env.NODE_ENV === 'development') {
const whyDidYouRender = require('@welldone-software/why-did-you-render');
// ...
}
makes sure that it doesn't affect the production code.
from why-did-you-render.
@vzaidman
Just checked - same for prod - WDYR itself does not called, but the code is there, and lodash is there, and override is there.
With all process.env.NODE_ENV === 'development'
checks.
from why-did-you-render.
Gotcha. I'll make sure there's no window._
override and revise the guidelines not to include the line importSource: '@welldone-software/why-did-you-render'
in process.env.NODE_ENV === 'development'
.
I'd also try to find a way to compile the library as an empty file with console.error
or something if the app is included in prod. The library should not be included in prod in any capacity.
from why-did-you-render.
@vzaidman It still corrupts results on dev for me. Some parts of app does not work when window._
is overridden.
Also, when it is switched off it is still ends up in the source code (and imports lodash) because of importSource: '@welldone-software/why-did-you-render',
I guess.
from why-did-you-render.
OK I finally got to look at it. This is a very annoying issue indeed.
-
lodash does not seem to be present in my prod no matter what I do. Please re-confirm this if possible @extempl.
-
In dev, the issue is essentially webpack/webpack#4465. I couldn't reproduce it initially because I've been building with rollup and I assume you've been using webpack. The thing is that because my library doesn't build lodash or pack it in any way, but just imports it, the issue is between you, your building infra and lodash (the issue linked above). Now I know you didn't import lodash so it's a nuasance you didn't call for, but I can't do anything in this regard, it's a lodash<>webpack issue. If you want, call
lodash.noConflict();
before or after importing WDYR like in the example below, but I don't want to calllodash.noConflict();
myself because it might introduce an unexpected behaviour for users relying on it.
if (process.env.NODE_ENV === "development") {
const lodash = require("lodash");
lodash.noConflict();
const whyDidYouRender = require("@welldone-software/why-did-you-render");
whyDidYouRender(React, {
trackAllPureComponents: true,
});
}
from why-did-you-render.
I ended up removing WDYR from the code, adding it manually locally only to check something, never committing to repo.
But it would be easier to not do that of course.
I do not remember exactly, but I think what I meant by description here
Please use tree-shaking (babel-plugin-lodash) or separate packages (aka import deepClone from 'lodash.deepClone')
is that we actually use both of these approaches and it does not override window._
, while WDYR (and only it) uses full import which does that override. So I still think this is the problem in how you do it in WDYR (Or, rather, how you could fix it. I doubt there are users of WDYR that are relying on WDYR's lodash in window._. And if there are… Well…).
I have a project where react co-lives with backbone (… hard to get rid of it), and all that with lazy loading and switching one with another, so what I did initially was that conditional noConflict
and that was honestly hell. Until I found that WDYR import responsible for that and just removed it completely.
Perhaps that is webpack issue that it includes full lodash, if lodash is partially used in the project with tree-shaking, if some of packages includes full package. Some kind of optimisation? That's why you might not have it in your prod bundle.
So, I still believe that the easiest way would be to fix imports in WDYR.
from why-did-you-render.
Related Issues (20)
- dom npm
- wdyr not work in next13 (repo provided) HOT 2
- wdyr not work in next13 (repo provided)
- Cannot get WDYR output from nextjs dynamically loaded component (e.g. for no-ssr use case) HOT 2
- Project still being actively maintained? HOT 2
- Multiple React roots
- why-did-you-render + React Query
- No logs or anything about WDYR HOT 9
- Missing `ownerDataMap` in `notifier`
- Partially Working with React 18 + NextJS 13
- "Support for defaultProps will be removed" error after setting include: [/./] option HOT 2
- Tracking custom hooks issue HOT 2
- WhyDidYouRender is not working in Storybook.js
- Property 'React' doesn't exist HOT 1
- react-refresh-webpack-plugin not updating component when wrapped with React.memo.
- `trackAllPureComponents: true` is not working
- Next.js example is missing
- Links from the Credits section are broken HOT 1
- wyd support to react 19 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from why-did-you-render.