![Oracle Drags Its Feet in the JavaScript Trademark Dispute](https://cdn.sanity.io/images/cgdhsj6q/production/919c3b22c24f93884c548d60cbb338e819ff2435-1024x1024.webp?w=400&fit=max&auto=format)
Security News
Oracle Drags Its Feet in the JavaScript Trademark Dispute
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
react-ssr-fork
Advanced tools
React SSR Fork facilitates rendering different content on server and client side.
React SSR Fork facilitates rendering different content on server and client side, and solves hydration mismatch issue.
<Client>
component to render client side content, and <Server>
for server sideInstall the library:
npm install --save react-ssr-fork
Wrap your main application component inside <ForkProvider>
. This component contains the business logic of solving hydration mismatch issue, also provides context for <Client>
and <Server>
components.
<ForkProvider>
wrapping is obligatory on client side):// client.jsx
import React from 'react';
import ReactDOM from 'react-dom';
import { ForkProvider } from 'react-ssr-fork';
import App from 'your-components/App';
ReactDOM.hydrate(
<ForkProvider>
<App />
</ForkProvider>,
document.getElementById('root')
);
<ForkProvider>
wrapping can be skipped on server side):// server.jsx
import React from 'react';
import { renderToString } from 'react-dom/server';
import { ForkProvider } from 'react-ssr-fork';
import App from 'your-components/App.jsx';
const content = renderToString(<App />);
// ...
<Client>
component to render client side content, and respectively <Server>
to render server side content. Your <App>
component might look like this:// App.jsx
import React from 'react';
import { Client, Server } from 'react-ssr-fork';
export default function App() {
return (
<div>
<Client>
I run on client
</Client>
<Server>
I run on server
</Server>
</div>
);
}
Here's what happens when you run the application:
<App>
simply renders <div>I run on server</div>
<App>
renders <div>I run on server</div>
(to match the content sent from server), then right away re-renders to actual client content <div>I run on client</div>
.<Client>
and <Server>
need to be wrapped inside <ForkProvider>
on client side. While on server side <ForkProvider>
is not obligatoryReactDOM.hydrate()
. Do not use it with ReactDOM.render()
this.state.isCient
approach?ReactDOM.hydrate()
documentation suggests solving hydration mismatch warning using two-pass rendering and this.state.isClient
flag. Here's a simple imlementation:
import React, { Component } from 'react';
class Message extends Component {
state = { isClient: false }
render() {
return (
<div>
{this.state.isClient ? 'I run on server' : 'I run on client'}
</div>
);
}
componentDidMount() {
this.setState({ isClient: true });
}
}
ReactDOM.hydrate(
<Message />,
document.getElementById('root')
);
On client side during initial render this.state.isClient
is false
. Thus <Message>
outputs <div>I run on server</div>
. This output matches the one sent from server side, and React doesn't throw any mismatch warnings during hydration.
Right away after mounting of <Message>
, componentDidMount()
method is invoked and this.state.isClient
becomes true
. As result <Message>
renders <div>I run on client</div>
.
As described above, solving hydration mismatch using two-pass rendering works.
But there is a drawback. If a new instance of <Message>
is rendered on the client side on later stages, two-pass rendering will be applied even if that's unnecessary. This makes your component slower. That's the problem solved by React SSR Fork library, which prevents unnecessary re-rerending.
React SSR Fork components faciliate unit testing of your components.
<ForkProvider>
accepts a special boolean prop canUseDom
. Use to set manually client or server environment in your unit tests. For example:
import React from 'react';
import { mount } from 'enzyme';
import ForkProvider from 'components/fork-provider';
function App() {
return (
<div>
<Client>
I run on client
</Client>
<Server>
I run on server
</Server>
</div>
);
}
describe('<App>', function () {
test('renders client content on client side', function () {
const wrapper = mount(
<ForkProvider canUseDom={true}>
<App />
</ForkProvider>
);
expect(wrapper.contains('I run on client')).toBe(true);
expect(wrapper.contains('I run on server')).toBe(false);
});
test('renders server content on server side', function () {
const wrapper = mount(
<ForkProvider canUseDom={false}>
<App />
</ForkProvider>
);
expect(wrapper.contains('I run on client')).toBe(false);
expect(wrapper.contains('I run on server')).toBe(true);
});
});
FAQs
React SSR Fork facilitates rendering different content on server and client side.
The npm package react-ssr-fork receives a total of 0 weekly downloads. As such, react-ssr-fork popularity was classified as not popular.
We found that react-ssr-fork demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
Security News
The Linux Foundation is warning open source developers that compliance with global sanctions is mandatory, highlighting legal risks and restrictions on contributions.
Security News
Maven Central now validates Sigstore signatures, making it easier for developers to verify the provenance of Java packages.