Hi, I had a general doubt over why using these binding are necessary. I can straight away see that, yes we need React bindings since we do not have the good old javascript. But, if I do not require the JavaScript, does it make sense to use a React component for a simple grid like
<Grid>
</Grid>
instead of rendering it as
<div class="ui grid">
</div>
Note that in the second case I've loaded the semantic.min.css in my index.html page so that does work. As for just design and non-JavaScript aspects, is there any caveat that I'm missing out for using react bindings over SUI tags. Ofcourse, keeping aside the usual advantages such as re usability of react components, etc etc.
On a more general note. Is it not advised to use the jQuery with react which is why using react bindings helps? I've seen some answers in the past about the general usage of mixing jQuery with react but haven't gotten any solid reason for it.
Any feedback is greatly appreciated!
There is awesome and detailed answer why you should prefer components instead of raw HTML markup.
Semantic UI React doesn't provide any styling currently, it's generates a valid markup. So you still need SUI's CSS. However, this can be changed in future (#1579).
Semantic UI React components doesn't depend on jQuery at all, mixing React and jQuery is the antipattern in most cases.
Although it was a very good read. Apart from the aesthetic nature of why reusing components for building apps is natural, I didn't find it technical at all! Maybe it's just me :( I would appreciate if someone could answer this on some technical grounds.
Keeping aside all the convenience and assuming I'm willing to painstakingly write out each element (because I can :P) , does it defer the React rendering or performance in any way?
@layershifter Could you please open this again to address the performance advantages of SUI react over SUI?
@saikrishnadeep From the Facebook React docs: https://facebook.github.io/react/docs/integrating-with-other-libraries.html
_Technically_, as long as you are 100% positive you are not manipulating the DOM in any way with jQuery that is being controlled by React, you can do it. If you were working on an extremely simple project, it would be much easier. Once you get into a more complex application and you want to reuse components and nest them, managing that can easily become a nightmare when you are reusing and nesting components.
Basically manipulating the DOM that React controls can cause all kinds of problems in React in the shadow DOM.
That answer was more directed at the props vs className discussion. Reasons for using SUIR over SUI are detailed in the docs:
http://react.semantic-ui.com/introduction
The primary reason is that we removed all jQuery and rewrote the components in React. Everything else is bonus material.
@brianespinosa is absolutely right, though I'd extend this statement:
If you were working on an extremely simple project, it would be much easier.
Even a simple project uses a Dropdown. Try using a SUI jQuery dropdown with dynamic options in a React app and you'll understand the exact reason I wrote SUIR :)
Aside from the "patterns" vs "antipatterns" debate, does using semantic-ui-react over it's jQuery cousin yield any real world performance benefits? Or has this package merely been developed to appease React purists?
@s-devaney it's not about performance benefits as per some of the links and comments previously shared in this conversation thread.
Even a simple project uses a Dropdown. Try using a SUI jQuery dropdown with dynamic options in a React app and you'll understand the exact reason I wrote SUIR :)
I think the best answer is, don't use it. Try SUI in React for 6mo.
I get the ease of use angle. I was trying to understand the performance implications of using this over the vanilla SUI library - which is quite heavy in itself. Presumably abstracting all of that with a virtual DOM in React will make it even less performant?
Note that SUIR isn't used on top of SUI. SUI is written in jQuery while SUIR is a complete rewrite (port) of SUI from jQuery to React.
Both libraries use the same CSS, but their own JS. Also, React's virtual DOM patching algorithm is far faster than jQuery's direct DOM manipulations 馃槈
Most helpful comment
@brianespinosa is absolutely right, though I'd extend this statement:
Even a simple project uses a Dropdown. Try using a SUI jQuery dropdown with dynamic options in a React app and you'll understand the exact reason I wrote SUIR :)