I am using Tailwind in my Next.js application and it sometimes behaves strangely. I could get 99% of the classes work but in some occasions classes doesn't apply at all. Just to give an example, when I add h-48 which produces height:12rem; its completely fine but when its changed to number above 48 it doesn't work like h-96.
Another problematic class is max-height. Regardless of the value it doesn't apply at all. Same thing happens with any classes that has point in it. For example m-h-0.5.
At the same time, if I change the config file and assign h-96 to any value it still applies. What do you think that might be causing tailwind to behave in that way?
I ran into this issue just now and found the fix.
This happens if you don't have a postcss.config.js config in your root. This happened to me because I was upgrading from an older version of Tailwind and for some reason that config hadn't been generated initially. You can use tailwind to generate a new one - just run the below code in your root.
npx tailwindcss init -p
Related
I was trying to integrate a React.js app in Cordova. Everything goes well, but I was not able to debug the app in the simulator. With chrome://inspect it seems like there's no way to do it, because I can only see the "compiled code". Any solution? Thanks
Maybe there is another better way, but what do the trick for me is to build react with some custom files that i took from node_modules/react-scripts/
(i do that, to avoid react eject)
You need all the sources map on your app.
React by default, use a certain webpack config, but that config doesn't work in your phone.
By default, react use this
You can check it on the file node_modules/react-scripts/config/webpack.config.js
What i do, is to build react with the next webpack config
devtool: "eval-source-map",
So you must
Copy these files on your source code and adapt some imports (there are some import with relative path) You only need these two files
node_modules/react-scripts/scripts/build.js
node_modules/react-scripts/config/webpack.config.js
On the first one, modify it to use the second one,
On the second one, add this devtool: "eval-source-map"
Create new task on package.json , new custom build to use the script your custom build.js
Build with this script, and copy all the source maps with your code, and thats it.
The debug could crash sometimes, (i try it also with iphone + safari, sometimes works, sometimes don't so you must keep trying)
On android tend to work in a better way.
The debug is a little bit slow in compare to the web debug.
I hope this works for you too.
(Sorry for my bad English)
I have a sort of a "monorepo", one big project consisting of a few smaller projects that use React.
I'm trying to break these up into three separate repositories, lets call them Core, Application1, and Application2
The Core is a dependency of both applications, and the Core depends on React, because it defines some React component classes. The applications both also use React.
When I tried to build this all together (using Parcel bundler), I am getting a final bundle which at runtime gives the Invalid Hook Call warning in one (but not both) of the applications.
On that page (or in the error message), it says that the error could be caused by one o these:
You might have mismatching versions of React and React DOM.
You might be breaking the Rules of Hooks.
You might have more than one copy of React in the same app.
I have checked that #1 is not true, and I'm not even using hooks in any way that I am aware of, so the problem is seems to be multiple versions of React.
I gathered from reading about this that it was a mistake for my Core library to declare React as a dependency, and that it should instead declare it in peerDependencies. That made the Application stop giving the error, but it also made my Core library start having a bunch of Typescript errors and failing to be able to run the unit tests (which rely on React, using Jest/Enzyme to render and validate DOM).
Since specifying React in peerDependencies caused it not to be installed in the node_modules of Core, I decided that I should probably include React in both the peerDependencies and the devDependencies of Core. That fixes the Core library again but breaks the Application.
I'm not really sure of the following:
Why one of my applications fail due to duplicate React copies and the other doesn't, since they seem pretty symmetrical to each other.
Why, even though I only specify React in peerDependencies and devDepenencies in Core I still would get a duplicate copy of React in the dependent application
Whether the method used to bring Core in to the application has any bearing on this. (one method I'm trying is package.json I specify core as a "file:../" style of URL. Another alternative is to use "yarn link", or possibly to do both of these, and I'm not sure whether this has any effect on what ends up in node_modules underneath the application folder or on what gets bundled)
What is the right way to include React in both an Application and a library, in such a way that both of those projects have React available but there does not end up being duplicates in the Application causing this hook error (or, just taking up extra space).
Answering my own question.
I found the following issue helpful: https://github.com/facebook/react/issues/14257
Various different suggestions were made in the comments of ways to solve this problem, either by npm link or yarn linking the react library from the library to the application, or vice versa. Those all seemed promising, since the idea is to make sure that all of the different references to React are actually pointing to the same place. Unfortunately none of those worked for me. (e.g. the answers by JerryGreen and Kas in that issue)
Another user, dcecile, suggested using webpack's alias feature, but I'm not using webpack.
resolve: {
alias: { react: require.resolve("react") }
},
Parcel has a similar alias feature but can't be used in quite the same way because it's used in the package.json file so things like require.resolve can't be called like they are in webpack's js config file.
I ended up finding a way to use Parcel's alias feature to do what I wanted, based on another example from https://github.com/jaredpalmer/tsdx/issues/64 from user jaredpalmer. In my situation, I'm adding this to the application's package.json, and it appears to get rid of the duplication problem and the "Invalid Hook Call" error:
"alias": {
"react": "../my-core-library/node_modules/react",
},
Actually, I know my question is s weird but really confused me. lodash functions are awesome and using them is a safe way to have a secure and clean code but in my react project when I use get function of lodash, in the development environment it works well as every developer expected.
import get from 'lodash/get';
const hostname = get(window, 'location.hostname');
// => returns the current hostname
But after I run yarn build && yarn start to make a production build of my ReactJS app and run it, its behavior is changed and returns undefined.
import get from 'lodash/get';
const hostname = get(window, 'location.hostname');
// => returns undefined
So in the production build, I try the get(window, 'location') and it returns the location object. but when I put a key of location the lodash get function returns undefined.
Actually, in the production and just for nested it returns undefined
Due to this issue, I just found this post, but no one answer it.
According to this comment I became passionate about testing my production build. So I listed all thing That happens on the production build of my project that maybe causes this issue.
At first, I doubted to babel plugins that I used for transpile, but none of them affect just on production, they affect for whole environments.
And at last, I find LodashModuleReplacementPlugin. this plugin causes this issue.
Based on its doc:
Deep property path support for methods like _.get, _.has, & _.set.
This plugin omit the deep path support on lodash get. That's the point.
have very simple sample app which build Create React App + Styled-Components to prove this issue. But I have real big application which I am facing this issue which I am going to explain it below.
I would like to pre-render this app with Rendertron for SEO/GoogleBots and etc. But the problem is when I build PRODUCTION version of React App which use Styled-Components . all the style will be missing on static version which Rendertron produced, but from other side if I try the same workflow with dev-server of app , everything looks fine .
So far I know there is different on PROD version and DEV version of my application when I render it with Rendertron . But I am not sure what cause this issue and how I can fix this issue .
I am looking for solution or idea which can help me to solve this issue .
Here is my sample code which I peppered for test .
https://github.com/AJ-7885/test-styled-component-with-rendertron
Here is screen shot from different version of Rendered version by Rendertron base on PROD or DEV version of the same application .
enter image description here
After a lot of searching around, I finally found out the reason. The Styled Components library uses something called the "Speedy mode" to inject styles on production. This makes the styles bypass the DOM` and be injected directly inside the CSSOM, thus, appearing in the inspector, but totally invisible on the DOM.
Fortunately, Styled Components 4.1.0 came with a fix for this issue! Now you can set a global variable called SC_DISABLE_SPEEDY to true in order to disable the Speedy mode and get the styles to appear on Production as well.
Reference: https://www.styled-components.com/releases#v4.1.0
But the only part I am not sure , how to set disable this Speedy Mode in Create-React-App without Ejecting , Dose any body has any idea ?
You need to render your styles on the server side and inject those styles in your pre-rendered react app. Styled-components explains how to do that here: https://www.styled-components.com/docs/advanced#server-side-rendering
Also, I'd recommend using react-snap for pre-rendering since that is recommended by the Create React App docs. react-snap seems to be more of a React-specific solution that may be easier to implement, especially with styled-components.
I read various answers like this regarding reducing the bundle size. First I wanted to understand what is going on with my 13MB bundle, so I've installed the Webpack Bundle Size Analyzer. It generated this output:
There are a few things I don't understand:
Why is react appearing twice with two different sizes?
How come it doesn't add up to 13MB? (it's around 4.75MB)
Does this means my own code is only 4KB? (last line)
Is it possible to understand from this tree how to save KBs? I mean, for instance, is there a way to use only parts of lodash or is it required as a whole by React?
Update:
Found the answer for #1. React-color requires ReactCSS which requires a different version of react and lodash. Without React-color my bundle dropped from 13MB to 8MB. I will try to find a way to re-use react and lodash.
It seems that you have eval-source-map devtool option in your webpack config file, that's why you are getting such huge bundle size. This way, sourcemaps are putting inside of bundle js file.
Try to change this option to source-map to build source maps separately.
// webpack.config.js
{
devtool: 'source-map',
// ... other options
}
1) Sometimes other dependencies require again lodash and / or react, so these dependencies are pulled in multiple times by webpack (usually happens when the version differs), here the DedupePlugin should help. The final bundle size also depends on your devtool entry in webpack, so in development it is usually much bigger as you probably have sourcemaps enabled and a your build is not optimized. Hard to tell without your actual webpack config.
2) Maybe webpack is already deduping?
3) last line says 400KB
4) You can definitely save a few kbs. A good way to start is using lodash-webpack-plugin with babel-plugin-lodash, this will import only the lodash methods you are actually using instead of the complete library. You can also just require the bits you need from material-ui as outlined in this answer.
I recently added the webpack-dashboard to my webpack config, so I instantly see the output and percentages that make up my bundle size, so maybe you think twice about adding huge dependencies if you don't really need them.