React Color – Color Pickers from Sketch, Photoshop, Chrome and More(casesandberg.github.io) |
React Color – Color Pickers from Sketch, Photoshop, Chrome and More(casesandberg.github.io) |
I'm all for innovation and advancing the state of the art, but there has got to be a better way of dealing with these basic components. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping StackOverflow in business.
I bet this guy learned a ton and has a nice widget on his resume.
> frustrating those with none
The idea is that they gained some advantage from chosing the latest and greatest framework. If that's not worth having to make a widget like this yourself, then you should've chosen old reliable instead.
source? In reality, it's quite the opposite. You can't easily convert a React component to another framework. The key to writing reusable code is to remove dependencies.
In the long run, shadow DOM should make it easier to make framework agnostic widgets.
fwiw, I thought this little project was really cool.
I'm all for innovation and advancing the state of the culture, but there has got to be a better way of dealing with these basic emotions. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping the Record Industry in business.
I'm not a React specialist and I have the following question : Is it that common to write the CSS inside the JSX file?
Since I started learning React, the hardest part to swallow was that my HTML and JS now live in the same file. Now I see that this library also puts the CSS and since I'm not entirely sure if this is good or not, can someone point some Pro's and Cons and if it's common or not.
If you know of a color-picker design that is better spaced (mobile friendly) go ahead and open up a issue on the repo and paste it in there. I am going to be going through this week and making a couple more!
Edit: to elaborate, the layouts are generally fine, you just need fatter sliders and more space between the buttons.
Like with most new technologies, we're currently in the phase where we're overusing it. In the long run, this will hopefully even out into a state where React-style DOM abstraction instead becomes just one more tool to be used when appropriate.
[1] https://aerotwist.com/blog/react-plus-performance-equals-wha...
At least on my 1.82 GHZ Core duo
The Sketch colour picker in the second sample in More Examples has no alpha, yet displays an editable field for it. Furthermore, while a text box for the colour component has focus, dragging of the label below it changes the colour, but not the value in the text box. And I think for all "dialog-like" colour pickers the text box labels should actually be labels for the text box, that is, when clicked, they should put focus on the text box.
I noticed that it is trivial to break the whole thing in a way that would probably put off average users. (See Bug Report at bottom.)
I would like to read ideas here that weigh the merits of Web Components and other compartmentalized (web) programming techniques and their ability to still have the ability to fail globally, especially if they promote an environment that gives the (perhaps false) notion that 'What I do in this will not be a problem for you'. Is this a function of React(and similar), the programmer, or other? Is it even a thing at all?
Bug Report: Changing an integer value to "g" in the R field of "Sketch" breaks ALL widgets with the only apparent way of fixing is clicking a swatch or entering a valid hex where available. Clicking Up or Down arrows in 'Chrome' does not fix. Clicking in color areas of 'Chrome', 'Sketch', or 'Photoshop' does not fix. Inputting Valid RGB values into any field does not fix but reverts to NAN.
If you're using a backend server you're just rendering the react stuff to html and sending it to the client.
[1] http://workshop.chromeexperiments.com/examples/gui/#1--Basic...
* http://material-ui.com/#/components/appbar
* http://react-bootstrap.github.io/components.html
You are.
Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.
http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...
Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies.
[edit]
Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.
In Web Components writing specific CSS for a component is fine. And it wont pollute or over-rule your other css rules. Since its the shadowdom
That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications.
There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.
And caching problem would be if I have 2 server rendered pages ( even with JSX that's possible ) and have same styles which will be downloaded twice from two js bundles.
I think separation of those is still better solution. Not to mention stylesheet commits that are far easier to follow than just modifying a js file.
CSS in JS is about leveraging the (relatively sane) variable/procedure declaration and control flow semantics that are already available to you in JavaScript. How you deliver them to get the best possible performance is a wholly different problem.
[1]: https://github.com/kodyl/stilr [2]: https://github.com/robertknight/ts-style [3]: https://github.com/chenglou/RCSS
Anyway, it's not a panacea. It can't do much if you're forcing a reflow every few milliseconds.
It would seem to me, again completely without knowledge, that a virtual DOM seems suboptimal. Web browsers should be able to optimize for that use case a lot better.
http://stackoverflow.com/questions/21109361/why-is-reacts-co...
It is challenging to make a large app with lots of state be performant when you manually mutate the DOM, and there's no way for the browser to fix that because of the way things work.
For example, if you move an element, and then request the position of another element immediately after, the browser will be forced to recalculate layout before giving you an answer. With lots of state and lots of updates, it's very challenging to keep this in the right order.
As virtual DOM is an abstraction over the DOM, you can make a vanilla app that is much faster, but as your app grows, that quickly reverses.
Virtual DOM makes sense when (A) you have a huge tree and (B) you show only a small portion of that tree to the user at any given time.
For example a long scrollable list or a multi-line text editor would be better implemented with virtual DOM, but using it everywhere is an overkill.