Inconsistent classNames between server and client rendered components - material-ui

I have an issue whereby my client rendered components class names (custom class names created with makeStyles) are of the format jss1234, however when rendering on the server they are of the format makeStyles-name-1234. Causing issues when I then hydrate.
I have followed the server side set up here: https://material-ui.com/guides/server-rendering/#handling-the-request pretty much to the letter.
My client entry point looks something like:
const Main = () => {
useEffect(() => {
// clean up any server side generated styles
const jssStyles = document.querySelector('#jss-server-side');
if (jssStyles) {
jssStyles.parentNode.removeChild(jssStyles);
}
}, []);
return (
<ThemeProvider theme={ theme }>
<BrowserRouter>
<App />
</BrowserRouter>
</ThemeProvider>
);
};
ReactDOM.hydrate(<Main />, root);
This is only an issue in production and I have ensured that both my server and client side code have process.env.NODE_ENV === 'production'.
I don't mind which format my classnames are, as long as they are consistent. I have tried using the StylesProvider and creating a new generateClassName function to force one way or the other, but it just doesn't seem to work. Client is always jss and server is always makeStyles prefixed.
Is there any other method of configuring this that I am missing?
thanks, in advance, I will update the question with any more information as I find it.
Update
On closer inspection it looks as though I cannot override the generateClassName function, I pass one in and a function is generated, but its not that one that gets called.
I have the following:
const generateClassName = createGenerateClassName({ disableGlobal: true });
const css = new ServerStyleSheets({ generateClassName });
const markup = ReactDOMServer.renderToString(
css.collect(
<StylesProvider generateClassName={ generateClassName }>
<ThemeProvider theme={ theme }>
...
and in my client:
const generateClassName = createGenerateClassName({ disableGlobal: true });
return (
<StylesProvider generateClassName={ generateClassName }>
<ThemeProvider theme={ theme }>
...
But the disableGlobal never takes effect, it looks as though it never actually uses this function. I must be missing some configuration, however I find the documentation about this stuff a little fragmented and it seems to suggest I wouldn't need to use StylesProvider on the server with the new API.
thanks in advance.

I had the some problem. I follow the exact tutorial in https://material-ui.com/guides/server-rendering/#handling-the-request. The development build works fine, but when running the production build on node, the server side rendering used development class names, causing a class mismatch on hydration.
I solved this by including the NODE_ENV enviroment variable on node bootstrap on production server.
NODE_ENV=production node server.js

So as it turns out this was indeed an issue with NODE_ENV.
In my case I was compiling my client code with webpack, but not the external node modules (using webpack nodeExternals). The command to do this was something like:
NODE_ENV=production webpack ... && node server.js
changing these to seperate npm tasks or something like:
NODE_ENV=production webpack ... && NODE_ENV=production node server.js
This solved the issue and I have been able to remove the StylesProvider from my code, as it is not needed with the new MUI v4 API.
Thanks and keep up the good work.

Related

Specifying window (global) variable type hinting in VSCode from external JS file without typescript

This may be a silly question but I really don't know where to look.
I'm creating a browser testing environment for a pretty large-scale API written in typescript. This API uses esbuild to build the typescript files into a /dist/ folder with a single index.js entry-point and its appropriate d.ts file.
I've created a /tests/ folder to hold some browser files that includes an index.html file with Mocha and Chai imported. It also imports /dist/index.js which is set globally to a window.myAPI variable.
In /tests/index.html:
import * as myAPI from "./dist/index.js"
Alongside index.html in the tests folder, there are separate JS files included for different tests that run things on window.myAPI... to do assertion tests.
search.test.js
book.test.js
navigate.test.js
I then run a server to host at the root. These separate tests are then imported from /tests/index.html. The separate tests look like this inside:
const { chai, mocha } = window;
const { assert } = chai;
describe("Search", function() {
describe("Setup", function() {
it("Setting URL should work", function() {
const call = myAPI.someCall()
assert.ok(call);
});
});
});
mocha.run();
Everything works, but I have no code hinting for myAPI. I'd like to be able to see what functions are available when I type myAPI, and what parameters they take, and what they should return - along with all my comments on each function.
In typescript you can do things like ambient declarations, but I don't want to make my tests typescript because then I add an unnecessary build step to the tests. But it would be as easy as:
/// <reference path = "/dist/index.d.ts" />
How can I tell VSCode that window.myAPI is an import of /dist/index.js and should import the types as well so I can see them ?
I'm open to different solutions to this, but I feel like this should be pretty simple. I don't know if ESLint is capable of doing something like this, but I tagged it because I feel it's relevant.
Thanks!

Stop huge error output from testing-library

I love testing-library, have used it a lot in a React project, and I'm trying to use it in an Angular project now - but I've always struggled with the enormous error output, including the HTML text of the render. Not only is this not usually helpful (I couldn't find an element, here's the HTML where it isn't); but it gets truncated, often before the interesting line if you're running in debug mode.
I simply added it as a library alongside the standard Angular Karma+Jasmine setup.
I'm sure you could say the components I'm testing are too large if the HTML output causes my console window to spool for ages, but I have a lot of integration tests in Protractor, and they are SO SLOW :(.
I would say the best solution would be to use the configure method and pass a custom function for getElementError which does what you want.
You can read about configuration here: https://testing-library.com/docs/dom-testing-library/api-configuration
An example of this might look like:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
You can then put this in any single test file or use Jest's setupFiles or setupFilesAfterEnv config options to have it run globally.
I am assuming you running jest with rtl in your project.
I personally wouldn't turn it off as it's there to help us, but everyone has a way so if you have your reasons, then fair enough.
1. If you want to disable errors for a specific test, you can mock the console.error.
it('disable error example', () => {
const errorObject = console.error; //store the state of the object
console.error = jest.fn(); // mock the object
// code
//assertion (expect)
console.error = errorObject; // assign it back so you can use it in the next test
});
2. If you want to silence it for all the test, you could use the jest --silent CLI option. Check the docs
The above might even disable the DOM printing that is done by rtl, I am not sure as I haven't tried this, but if you look at the docs I linked, it says
"Prevent tests from printing messages through the console."
Now you almost certainly have everything disabled except the DOM recommendations if the above doesn't work. On that case you might look into react-testing-library's source code and find out what is used for those print statements. Is it a console.log? is it a console.warn? When you got that, just mock it out like option 1 above.
UPDATE
After some digging, I found out that all testing-library DOM printing is built on prettyDOM();
While prettyDOM() can't be disabled you can limit the number of lines to 0, and that would just give you the error message and three dots ... below the message.
Here is an example printout, I messed around with:
TestingLibraryElementError: Unable to find an element with the text: Hello ther. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.
...
All you need to do is to pass in an environment variable before executing your test suite, so for example with an npm script it would look like:
DEBUG_PRINT_LIMIT=0 npm run test
Here is the doc
UPDATE 2:
As per the OP's FR on github this can also be achieved without injecting in a global variable to limit the PrettyDOM line output (in case if it's used elsewhere). The getElementError config option need to be changed:
dom-testing-library/src/config.js
// called when getBy* queries fail. (message, container) => Error
getElementError(message, container) {
const error = new Error(
[message, prettyDOM(container)].filter(Boolean).join('\n\n'),
)
error.name = 'TestingLibraryElementError'
return error
},
The callstack can also be removed
You can change how the message is built by setting the DOM testing library message building function with config. In my Angular project I added this to test.js:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
This was answered here: https://github.com/testing-library/dom-testing-library/issues/773 by https://github.com/wyze.

Protractor Custom Locator: Not available in production, but working absolutely fine on localhost

I have added a custom locator in protractor, below is the code
const customLocaterFunc = function (locater: string, parentElement?: Element, rootSelector?: any) {
var using = parentElement || (rootSelector && document.querySelector(rootSelector)) || document;
return using.querySelector("[custom-locater='" + locater + "']");
}
by.addLocator('customLocater', customLocaterFunc);
And then, I have configured it inside protractor.conf.js file, in onPrepare method like this:
...
onPrepare() {
require('./path-to-above-file/');
...
}
...
When I run my tests on the localhost, using browser.get('http://localhost:4200/login'), the custom locator function works absolutely fine. But when I use browser.get('http://11.15.10.111/login'), the same code fails to locate the element.
Please note, that the test runs, the browser gets open, user input gets provided, the user gets logged-in successfully as well, but the element which is referred via this custom locator is not found.
FYI, 11.15.10.111 is the remote machine (a virtual machine) where the application is deployed. So, in short the custom locator works as expected on localhost, but fails on production.
Not an answer, but something you'll want to consider.
I remember adding this custom locator, and encounter some problems with it and realised it's just an attribute name... nothing fancy, so I thought it's actually much faster to write
let elem = $('[custom-locator="locator"]')
which is equivalent to
let elem = element(by.css('[custom-locator="locator"]'))
than
let elem = element(by.customLocator('locator'))
And I gave up on this idea. So maybe you'll want to go this way too
I was able to find a solution to this problem, I used data- prefix for the custom attribute in the HTML. Using which I can find that custom attribute on the production build as well.
This is an HTML5 principle to prepend data- for any custom attribute.
Apart from this, another mistake that I was doing, is with the selector's name. In my code, the selector name is in camelCase (loginBtn), but in the production build, it was replaced with loginbtn (all small case), that's why my custom locater was not able to find it on the production build.

How to fix this warning "useLayoutEffect" related warning?

I am using NextJS with Material UI and Apollo. Although, everything is working properly but the warning is not going. It seems to me that a lot of Material UI components are using useLayoutEffect which is warned by React. The error is below.
Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, useLayoutEffect should only be used in components that render exclusively on the client. See fb.me/react-uselayouteffect-ssr for common fixes.
The problem is solved. I was suspecting it occurred for Material UI but it is actually happening for Apollo. I am posting the solution here to let others know.
in Apollo configuration file I needed to say the application is using Server Side Rendering. Please check the code below. If you are not using TypeScript then just remove the Types. In the last line { getDataFromTree: 'ssr' } object solved the issue. I hope it will help you.
import { InMemoryCache } from 'apollo-cache-inmemory';
import ApolloClient from 'apollo-client';
import { createHttpLink } from 'apollo-link-http';
import withApollo from 'next-with-apollo';
type Props = {
ctx?: {};
headers?: {};
initialState?: {};
};
const createClient = ({ ctx, headers, initialState }: Props) =>
new ApolloClient({
cache: new InMemoryCache().restore(initialState || {}),
link: createHttpLink({ uri: process.env.API_ENDPOINT })
});
export default withApollo(createClient, { getDataFromTree: 'ssr' });
I had the same problem using jest, enzyme and Material UI, but I was not using Apollo. If you encounter this problem using Material UI, a simple work around is to add to your test config file (src/setupTests.js) the following:
import React from 'react';
React.useLayoutEffect = React.useEffect;
Sources: here and here and here.
Otherwise, if your stack includes Apollo, you could try

SAP UIveri5 Minimum example

I am trying to understand how UIveri5 works and how to apply it to my own projects, but due to the minimal documentation I am unable to create a minimal working example.
I tried to apply the code from https://github.com/SAP/ui5-uiveri5/blob/master/README.md to "my" minimal app ( https://ui5.sap.com/1.62.0/#/sample/sap.m.sample.Button/code/ ), but the IDE VS Code marks errors, since i.e. the commands export or define are not known and I don't see where UIveri5 loads them from. Also if I just execute uiveri5 in my command line as is, I am getting an error ( I guess from selenium ) that my Chrome binary is missing, but don't the drivers get downloaded automatically?
conf.js
exports.config = {
profile: 'integration',
baseUrl: 'localhost:8080/.../sap.m.sample.Button',
};
page.spec.js
describe('Page', function () {
it('should display the page',function() {
element(by.control({
viewName: 'sap.m.sample.Button.Page',
controlType: 'sap.m.Page',
properties: {
title: "Page"
}}));
});
});
It would be awesome if someone already build a minimal example and can share it. It would help me very much in understanding how everything works together.
The minimum example is right in the readme.md. The only problem I see here is with the baseUrl - this should be a valid URL to an existing app. If this is a sample app on your localhost, you need a dev server.