I'm a react noobie and trying to do all my element manipulation inside my components (willMount, didMount handlers, etc.) but I am sooooooo used to throwing everything into a doc ready function in a main.js file.
Having said that, what is the disadvantage of leaning on a main.js file for element manipulation?
React is a Virtual DOM and by manually editing the DOM you are skipping the most powerful feature of React.
Also, by not using the props and the states you are not really benefits from it.
If you like to gain the DOM element reference you can do it by using Refs but other then that I'll personally won't recommend that.
Related
I'm getting ready to do my first React project, and my reading has made it pretty clear that I need to let React handle all rendering with the virtual DOM, and that I shouldn't do any manual DOM operations that would interfere with the virtual DOM calculations.
What I can't figure out, however, is this:
Suppose that I have a React component rendered in div #app in a page with other HTML. Does this mean that I have to refrain from any ordinary JavaScript DOM operations anywhere on the page? Or can I safely use DOM operations elsewhere on the page as long as I leave the #app div and elements inside the actual React component alone?
EDIT: Motivating use case
My reason for considering having non-React components manipulate the DOM outside of the React component is mostly so that the HTML can be seen by Google without jumping through a lot of hoops. Suppose that I wanted some descriptive text about the app that would be useful for SEO, and that description might have some dropdown toggles, etc. (hence the DOM issue). Would I really want/need to write everything in React just because the complex UI of the app itself uses React, if the cost is making some text hard for Google to index?
Assuming your html file looks like this:
<body>
<div id="app"></div>
<div id="others"></div>
</body>
and React is initialized like this:
ReactDOM.render(<Component/>, document.getElementById('app'));
you can safely modify div#others and any parts of the DOM except inside div#app as it is managed by React.
I may be misunderstanding your question, but React would be a great candidate to handle all of your DOM "operations".
Your React components can live on the same page as elements that are manipulated with run-of-the-mill JS DOM operations, but you are introducing conflicting paradigms. If you ever think to yourself "I can't do this in React, but I know how to with jQuery", you are most likely missing something.
EDIT: Thanks for clarifying the use case. You definitely don't need to write everything in React. As others have said, I would advise you to leave the part of the DOM owned by React alone with your other JS. Fetch as Google looks like it could be helpful for exploring SEO in React.
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.
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.
Some of the non-react libraries I'm using perform some DOM generation with javascript. Ideally, I'd like this to occur in react's render cycle but react doesn't implement some DOM functions.
ie. one library wants to create a fragment for showing a title (using jQuery) which in turn ends up calling document.createDocumentFragment.
A simple work around is to have the library do it's rendering on component mount or update. But I'm trying to render using the virtual DOM. Is there a better approach to re-creating or porting the library?
You need a "Portal".
Take a look at https://github.com/ryanflorence/react-training/blob/gh-pages/lessons/05-wrapping-dom-libs.md
This explains the solution very well, like so:
Methodology:
DOM libs usually manipulate the DOM
React tries to re-render and finds a different DOM than it had last time and freaks out
We hide the DOM manipulation from React by breaking the rendering tree and then reconnecting around the DOM the lib manipulates.
Consumers of our component can stay in React-land.
I'm facing some issues when rendering a React component into the shadow DOM of a webcomponent.
I wrote a small piece of code to turn a React component into a webcomponent, but I want to render the
React component inside the shadow DOM of the webcomponent. But in that case, it seems that React is not able to catch UI events (click, keyPress, etc ...) anymore.
Let's take an example, let say that I have a first webcomponent <awesome-timer /> that render the React component inside the webcomponent node, and another webcomponent <less-awesome-timer /> that render the React component inside the shadow DOM of the webcomponent.
Both webcomponents use the same React component. However the one rendered inside the shadow DOM does not work, because click events on the button of the timer component does not trigger the bound function.
I guess React is not designed to handle such case, but I'd love to get more details about it.
The code of the example is available here : https://gist.github.com/mathieuancelin/cca14d31184bf4468bc1
Does anyone have an idea about it ?
I know this is kinda late but, I believe your issue when you pass any attributes to a web component they instantly become strings Because that's all you can pass to a web component. Now of course you can convert or cast them back to there original data type, except functions because once stringified they loose there scoping, lexical and all.
Now to your main question, you are were trying to pass you child element through the Main web components slot. Now you have to remember that once you pass anything to a web component you now have to use the webs components methods and return types to manage whatever you pass. So yes passing react into a web component will not work they you expect.
You will need to go back to whatever tool you use to build your web component and deal with the slot logic there. Since this is a very old post as are web components. You might not have had access to the modern web component build tool's we have today. I found Stenicl allows you to build and manage your web components in Typescript.
A good option is to change your pattern a little bit and just return web components from your react app.
Or you can use another really cool to call Lit-HTML or Lit-element. I believe they may have combined there core libraries. Anyway these tool will allow you to combine Reactjs and web components where lit-html gives you access to methods simial to Reactjs's life cycle methods. Anyway some good stuff to check out if your stuck at this point.