I'm completely asea here.
We had a working app build with an old Electron Forge (^5.2.4; 5.2.6) created using the old React template (1.0.2-1.0.4) with the usual suspects of React tech (react-redux, react-router, etc.)
Up until about 1-2 weeks ago everything has been fine. Now, after running its startup code, showing some components, doing some things, then we get a Variant 119 error (ref issues or multiple versions of React).
Since the code used to work the ref thing seems spurious, but I checked all our refs (there are a total of two). I did the usual npm ls and yarn list, even checked a lot of modules for additional Reacts, but found nada.
Our yarn.lock file has not changed other than some internal dependencies that aren't Electron or React related. No external components (BlueprintJS, Semantic UI React, ...) have changed over the course of working-to-non-working.
Here's the kicker: reverting to previously-working versions (including deleting node_modules etc.) doesn't help. The build machine is running the same version of NodeJS as it has been (10.15.mumble). I've tried to track down caches (including Yarn) and deleted them, deleted the out directory, done full rebuilds, etc.
What could be impacting an Electron Forge build like this? What other code, directories, caches, configurations, etc. should I be looking for?
That it impacts previously-working versions points me towards build/environment problems, although this happens across machines, which points back at the project. After multiple days bisecting and rebuilding and having the same thing happen I've paid a visit to Witt's End. And I don't like it there.
Looking at the error message, it lists two different reasons for the error. It seems you have ruled out multiple react instances in your code, but be wary if you use npm link as that can do weird things with dependencies.
So have you check to see if someone on your project team checked in something that is trying to use a ref where they shouldn’t as that will also cause this error
Related
I have just created a regular create-react-app application, with the aim of sketching out components for a future project. But I ran into the problem that in order to see at least some, even small, changes purely in the text of the rendering component, you need to completely reboot the server using npm start.
And so with everything. I can even delete all the files from the root folder where I installed create-react-app, and the site on 127.0.0.1:3000 will still work (I tried). What should I do to enable hot-reloading?
We have an application that has multiple packages linked using yarn link.
When developing our app, we run ‘yarn start’ at the root which runs react-scripts and fires up the local server which is webpack under the hood from CRA.
We then run yarn start on the package we are updating, this runs a watch using webpack.
When we make a change in a package, the change is detected and react-scripts server hot reload recompiles, but it takes almost 20 seconds for the compilation to complete and a few more seconds for the browser to then reload to reflect the changes made.
I recently updated our versions of react and react-scripts to the latest and it seems to take even longer than the previous versions so it’s now taking about 30 seconds to reload.
I was wondering if it’s because we aren’t using yarn workspaces or a monorepo in general.
Does anyone have any experience with this and know of anything to speed things up as it’s becoming painstaking to work on our application as it currently is.
We tried to migrate to vite, but our application is too big to overhaul.
We heard snowpack might help but not sure how to migrate to that.
Does anyone know of any other potential tweaks like doing something to source maps or any drop in replacement for webpack that can help, that works with linked packages?
Thanks
I'm confused why all the React tutorials I'm using to learn React have me installing libraries through npm rather than importing through CDN's (React, Redux, Material UI, firebase, etc). I thought CDN's were more efficient.
Any guidance on this would be helpful (this is my first time using VS code and installing packages like this, the only other website I've programmed I just imported bootstrap and jquery through CDN and coded in notepad++ :/)
While you can of course use a CDN to import scripts into your application (with, for example a <script> tag) npm is useful in the fact that when you build your React app it will bundle all the required modules together.
This can be advantageous in the fact that your users don't have to download any scripts when your application loads (which can take some users with slower connections a long time) since everything is bundled within your React app. Some applications depend on a lot of dependencies, and forcing every new user to download each script individually can cause speed issues.
At the end of the day, I don't think there is a right or wrong answer as to whether you should use a CDN or NPM, just understand that when you use NPM it bundles the required scripts into your app when you run npm run build instead of the user having to download them when they visit your site.
CDN's will only get you so far. In the industry you're going to be expected to have some experience with npm/yarn. If you keeping going down the frontend rabbit hole, you'll eventually run into things like Webpack and Babble which will help make your Javascript a lot more efficient and backwards compatible. Installing things through npm/yarn will also often offer a lot in terms of providing you with a better development environment (things like react-scripts, eslint, prettier, etc).
We're using Material UI in our project, but there're many components that's shared between a few projects, se I'm creating a React components library to share them.
But when I import the component from library, I got the warning about #material-ui/styles:
It looks like there are several instances of `#material-ui/styles` initialized in this application.
This may cause theme propagation issues, broken class names, specificity issues, and makes your application bigger without a good reason.
I've checked by npm ls #material-ui/styles that there're only a single version.
But this problem is still happening even I added #material-ui/core, #material-ui/styles to the peerDependencies.
How can I fix this?
From the Materal UI docs:
Possible reasons
There are several common reasons for this to happen:
You have another #material-ui/styles library somewhere in your dependencies.
You have a monorepo structure for your project (e.g, lerna, yarn workspaces) and #material-ui/styles module is a dependency in more than one package (this one is more or less the same as the previous one).
You have several applications that are using #material-ui/styles running on the same page (e.g., several entry points in webpack are loaded on the same page).
As said by #Code-Apprentice one or more libraries are using #material-ui/styles (I bet it's react bootstrap). It doesn't really seem to be harmful but one way of fixing it is removing dependencies that use the #material-ui/styles.
I have a React-webpack web app (client side only - no API server) and was tidying up the package.json file and it occurred to me that all of the dependencies are dev dependencies as you do not run the React web app in production - you build it and distribute the built files.
Is this right?
React and possibly ReactDOM would be dependencies. Any additional libraries you're using that appear on the page would also be dependencies (example: react-autosuggest). Everything else would generally be a devDependency.
There's no great consensus on this yet (see this webpack issue, for instance). Some folks want to do everything as a dependency, others as a devDependency, I'm sure you could make a case for bundled dependencies, etc. The solution I outlined above is a best practice that seems to work well. For example, if you're using a version range on a package, you likely wouldn't care about minor/patch version change to webpack, eslint, karma, mocha, etc. You'd most certainly care about even a patch level change to something like react, so it gets separated out into a much shorter dependency list. (Looking at one project, there seems to be a 4-5x difference between dependency and devDependency. It's much easier to spot the meaningful changes if you corral them into the dependency tree.)
Related: yarn takes the approach I outlined above.