According to the react docs, renderToString() creates extra DOM attributes that React uses internally such as data-reactroot whereas renderToStaticMarkup does not.
And I thought that ReactDOM.hydrate() enables event handlers to be attached to the markup which is string-rendered via renderToString(), thanks to that extra DOM attributes such as data-reactroot.
But I've tested myself that ReactDOM.hydrate() also works with the static markup which is rendered via renderToStaticMarkup(), which means that the combination of ReactDOM.hydrate and renderToStaticMarkup() successfully attaches event handlers to the string-rendered DOM.
According to the Dan Abramov's issue, hydrate() does not rely on the internal react attribute (data-reactroot)
Instead, use hydrate() to explicitly tell React to hydrate existing
HTML. Then it won't depend on whether data-reactroot exists or not.
So I might guess that it would always be better to use renderToStaticMarkup() instead of renderToString(), since performance would be more optimized by renderToStaticMarkup()
Is that ReactDOM.renderToString() just an old way before hydrate() released on React v16, only to be used with render() and dangerouslySetInnerHTML()?
Is it okay for me to think that we can always use renderToStaticMarkup() over renderToString()?
This question is related to my issue, but yet has no clarified answer.
Related
react-tabulator is a library providing an integration of Tabulator in React. Their solution to render a React component within a Tabulator formater uses this function. However, I don't think this is 100% correct, because based on the React doc on integrating React w/ plain JS, ReactDOM.unmountComponentAtNode() needs to be called on dispose in order to to some cleanup. I also communicated this to the author within a GitHub issue, and maybe he'll provide additional info.
My question: is there a hook/handler/way to receive notifications when a cell is being disposed? 1) This will allow me to call the mentioned method, so that React can do some cleanup. 2) This opens also the path towards an alternative approach, leveraging React portals.
Thank you in advance!
I have created an implementation using portals in this gist. It's a Storybook pages. I'm using semantic-ui-react in my project, so a copy/paste of the file may need adapting.
I don't know if it's OK to have thousands of portals. I.e. one per cell. Also, I didn't see any action do "dispose" a portal. I hope that disposing the DOM element where the portal was rendered suffices. Otherwise => memory leaks possible I think.
I was trying to understand what's the difference between ReactDOMServer.renderToString() and ReactDOMServer.renderToStaticMarkup() on React 16.8.6.
This is what I understood:
renderToStaticMarkup() is used on the server side when you just want to render the markup and don't want to hydrate it on the client side. (https://reactjs.org/docs/react-dom-server.html#rendertostaticmarkup)
renderToString() is used on the server side when you want to use the ReactDOM.hydrate() function to hydrate the application on the client side. (https://reactjs.org/docs/react-dom-server.html#rendertostring)
So, if I'm right, the only difference between this two methods is that renderToString() adds the data-reactroot on the main element of the application. React reinforces this on the renderToStaticMarkup() documentation:
Similar to renderToString, except this doesn’t create extra DOM
attributes that React uses internally, such as data-reactroot. This is
useful if you want to use React as a simple static page generator, as
stripping away the extra attributes can save some bytes.
If you plan to use React on the client to make the markup interactive,
do not use this method. Instead, use renderToString on the server and
ReactDOM.hydrate() on the client.
But, I was reading this issue on React's repository where Dan Abramov said:
Instead, use hydrate() to explicitly tell React to hydrate existing
HTML. Then it won't depend on whether data-reactroot exists or not.
And:
...The suggested migration path is to use ReactDOM.hydrate() which
completely sidesteps the problem because it doesn't rely on the
data-reactroot attribute.
So, my question is: Is data-reactroot relevant to the hydrate function in React or is the documentation wrong?
Understanding this will be really helpful to fix a bug I'm having while hydration.
is performace degraded if we use jquery with reactjs?
because jquery changes directly DOM elements where as reactjs works with Virtual DOM.
is there any example reactjs with jquery?
is performace degraded if we use jquery with reactjs?
Not necessarily.
because jquery changes directly DOM elements where as reactjs works with Virtual DOM.
You are correct that jQuery does not utilize React's virtual DOM. Aside from rewriting core parts of jQuery to utilize it, vanilla jQuery will not. A wrapping component that does participate in React's virtual DOM can patch it in though.
The performance of this entirely depends on your usage. Keep in mind that React does still manipulate the DOM at the end of the virtual DOM work.
You can find the most up to date, official example at the Use React with Other Libraries page of the official React docs but it is admittedly light on the details.
is there any example reactjs with jquery?
If you check out this unit of react-training on wrapping DOM[-manipulating] libraries you can find a beautiful, comprehensive example of using ReactJS with both jQuery and jQuery UI.
Using the result of that article as a baseline, you will be using jQuery at time of React's initial mount time to minimally to do the DOM work and provide classnames for styling as needed, and React's pre-render props changing lifecycle event to re-render from changes through React. You are obviously free to use other events, such as shouldComponentUpdate or manually triggering renders as well, as your needs dictate.
Your performance will largely be tied to what you do in that re-render step.
Here are some tips that may help stave off some common performance vampires:
Ensure you are caching selectors and functions wherever possible
Ensure collection member's identities are properly keyed so that they aren't resulting in constant cache misses and thus constant re-renders
Especially if you are using unidirectional data flows or immutable data stores.
Some mapping operating always return new objects and so need extra care or a different api call.
Aside from that, keeping in mind both React best practices and jQuery best practices will take you a long way.
At the end of the day it's just JavaScript - React tries to keep away unnecessary heavy true DOM object creation/manipulation where jQuery allows misusing it just fine - but there is nothing by its nature to prevent making a performant jQuery app.
The question here is not about is this a good idea or not, because there is a real use-case : I'm scraping a specific website from a headless browser for an internal service and I need to extract data from react.
From an active production application, I would like to retrieve props from the root component using only "pure" JavaScript. The only thing I got is a div right now.
The constraints are:
It must be done using pure JavaScript (or using standard React lib)
I cannot add/setup react-devtools extensions or things like that
So far I could always hack into an event handler that I would trigger to manage to enter into React context but I'm looking for cleaner alternatives, any ideas?
I just want to do something simple like:
ReactDOM.find('img')
I can't seem to find anything in the documentation that does this. Do I just need to use jQuery? In my componentDidMount method, I want to add a listener to all img tags.
React does not have wrappers for convenient DOM access / DOM manipulation similar to jQuery because React recommends against having to access the DOM at all.
The DOM should be treated just as a rendering layer, not as a data store - your application state should entirely reside in javascript. Hence you never need to either access the DOM nor query it.