Ask HN: How can we make React better?
67 comments
I wish non-css animations were easier!
If you have any animation where you want to tween the state yourself (say changing position as a function of time), then that requires updating the state at 60fps or whatever requestAnimationFrame goes at.
It feels philosophically wrong to do that under the declarative paradigm of react. React is supposed to be responsible for taking the state and "transitioning"(or diffing) the dom to the new state. By doing the tweening myself, it feels like I am polluting the state with a lot of transient junk (like current progress time, start/end keyframe states, entering/exiting elements, etc). This is especially bad if you want to be a redux purist and throw all my state into a global state! But at the same time I don't know where else I can put it.
I've completely avoided doing anything more complicated than a CSS transition since coming to react (long ago, which also means there could be better 3rd party libraries that solves this problem now that I don't know of). But is there a better way to make this work out of the box?
If you have any animation where you want to tween the state yourself (say changing position as a function of time), then that requires updating the state at 60fps or whatever requestAnimationFrame goes at.
It feels philosophically wrong to do that under the declarative paradigm of react. React is supposed to be responsible for taking the state and "transitioning"(or diffing) the dom to the new state. By doing the tweening myself, it feels like I am polluting the state with a lot of transient junk (like current progress time, start/end keyframe states, entering/exiting elements, etc). This is especially bad if you want to be a redux purist and throw all my state into a global state! But at the same time I don't know where else I can put it.
I've completely avoided doing anything more complicated than a CSS transition since coming to react (long ago, which also means there could be better 3rd party libraries that solves this problem now that I don't know of). But is there a better way to make this work out of the box?
It may feel excessive to rerender an animating component every animation frame, but in practice it’s generally “fast enough” and I find the declarative programming model very nice to grasp mentally.
Regarding the handling of timers, easing functions, etc., that does need to be handled somewhere, but it can be “componentized” so that you can reuse animation logic via a friendly component API without worrying about the underlying bookkeeping. You’ll have to learn and get used to that API, but when you find one that works for you it can be great. Two popular such libraries for React are react-spring and Pose:
http://react-spring.surge.sh/spring
https://popmotion.io/pose/learn/popmotion-get-started/
Regarding the handling of timers, easing functions, etc., that does need to be handled somewhere, but it can be “componentized” so that you can reuse animation logic via a friendly component API without worrying about the underlying bookkeeping. You’ll have to learn and get used to that API, but when you find one that works for you it can be great. Two popular such libraries for React are react-spring and Pose:
http://react-spring.surge.sh/spring
https://popmotion.io/pose/learn/popmotion-get-started/
This is a library that I've used before to handle some complicated animation: https://github.com/joshwcomeau/react-flip-move
No longer actively maintained, though, so you might want to check out https://github.com/aholachek/react-flip-toolkit instead.
No longer actively maintained, though, so you might want to check out https://github.com/aholachek/react-flip-toolkit instead.
I kinda enjoy working with React (because of JSX simplicity and composability). I think you could add easy support for some styling solution like it's done in Vue.
I would focus on making React stable, fast and lightweight but improve on tooling and ecosystem around it.
* I would like blessed way of extracting React components, so they can be reused between projects (like right click in IDE and share) - something like https://bitsrc.io/
* react addon for chrome could be much nicer (I have to dig through so many unnamed HoC sometimes).
* you could favor more beginner friendly state solution - something like https://github.com/solkimicreb/react-easy-state
* you could embrace typescript for easier usage experience
There could be some React plugin(kinda like http://demo.rekit.org/) for editors that would allow for:
* adding mock props to component and preview it on hover, click for example (kinda like styleguidist but with less setup overhead) * abuse above to provide out of the box image snapshot testing * simpler ability to add tests (like right click on component and "add assertion", "go to test") * some structured way of making components * swap between style, tests, data sources and logic * run tests only for this component * etc - basically more streamlined creation experience
Also please focus on debugging when introducing async rendering. (so there won't be errors out of nowhere in stack trace)
I would focus on making React stable, fast and lightweight but improve on tooling and ecosystem around it.
* I would like blessed way of extracting React components, so they can be reused between projects (like right click in IDE and share) - something like https://bitsrc.io/
* react addon for chrome could be much nicer (I have to dig through so many unnamed HoC sometimes).
* you could favor more beginner friendly state solution - something like https://github.com/solkimicreb/react-easy-state
* you could embrace typescript for easier usage experience
There could be some React plugin(kinda like http://demo.rekit.org/) for editors that would allow for:
* adding mock props to component and preview it on hover, click for example (kinda like styleguidist but with less setup overhead) * abuse above to provide out of the box image snapshot testing * simpler ability to add tests (like right click on component and "add assertion", "go to test") * some structured way of making components * swap between style, tests, data sources and logic * run tests only for this component * etc - basically more streamlined creation experience
Also please focus on debugging when introducing async rendering. (so there won't be errors out of nowhere in stack trace)
I'd just like to voice a -1 for TypeScript (or Flow for that matter)
In my experience it doesn't help people, especially at an earlier stage, but rather clutters what people already know about JavaScript. It causes tooling to slow down and ultimately doesn't prevent bugs that could not already be caught by good design and linting.
I'm much more of a fan of something like PropTypes, which isn't just superficial, but actually runs on your code in all places and will stop you passing the wrong types to components, regardless of what environment you're in.
Otherwise everything else on this list is a +1
In my experience it doesn't help people, especially at an earlier stage, but rather clutters what people already know about JavaScript. It causes tooling to slow down and ultimately doesn't prevent bugs that could not already be caught by good design and linting.
I'm much more of a fan of something like PropTypes, which isn't just superficial, but actually runs on your code in all places and will stop you passing the wrong types to components, regardless of what environment you're in.
Otherwise everything else on this list is a +1
TypeScript has been very helpful in our react projects. There isn't much clutter, as usually the only types you define are props and state – things you want to know anyway.
TypeScript doesn't prevent any bugs that tests would not, but it does so faster and more concisely.
Tooling slowdown depends on your tooling setup; TypeScript can compile JSX on its own.
PropTypes are useful if you're transitioning from a plain JS codebase. But if you can start with and go full TS, I highly recommend going that route.
TypeScript doesn't prevent any bugs that tests would not, but it does so faster and more concisely.
Tooling slowdown depends on your tooling setup; TypeScript can compile JSX on its own.
PropTypes are useful if you're transitioning from a plain JS codebase. But if you can start with and go full TS, I highly recommend going that route.
Please no typescript. Instead make Javascript better.
+1 for typescript
+1 for typescript support. This helps in reducing compile/build time errors and for the devs who are from java/c# background.
typescript++
Size. For my use case of a hybrid mobile app where I'd like to render lightweight webviews, the overhead of react is far too great.
For this i'll actually reach for Preact instead. Or perhaps even the relatively new Svelte (disappearing) framework.
For this i'll actually reach for Preact instead. Or perhaps even the relatively new Svelte (disappearing) framework.
Thanks for the feedback! We've found that in most cases the components you've built tend to be much larger than React itself, and indeed if we can reduce the size of your components by adding things to React then that is often a good tradeoff for us.
However we do try to keep the size down; for example React 16 included a 30% size reduction.
When you say "the overhead of react is far too great" are you speaking from something you tried that didn't work? I haven't heard any stories like this so would be interested to hear more if React was actually too slow for you.
(We're also working on our own optimizing compiler, but it's still a very experimental project at this stage.)
However we do try to keep the size down; for example React 16 included a 30% size reduction.
When you say "the overhead of react is far too great" are you speaking from something you tried that didn't work? I haven't heard any stories like this so would be interested to hear more if React was actually too slow for you.
(We're also working on our own optimizing compiler, but it's still a very experimental project at this stage.)
I'm playing around with react-dom-lite, and frankly it's exactly what I need - I'm getting less worried about IE support by the day, and it drops the bundle size by quite a bit.
I'd love to see React itself ship with options to drop polyfills and old browser support if it helps the bundle size.
I'd love to see React itself ship with options to drop polyfills and old browser support if it helps the bundle size.
Align with, improve, and build upon, Web Components specifications, as well as other ongoing W3C standardization efforts. I.e. be stewards of the Web Platform ecosystem.
Promote harmony, cross-compatibility, and longevity in the web development landscape.
Promote harmony, cross-compatibility, and longevity in the web development landscape.
I’ll bite. I have been frustrated with the lack of stable apis in JS in general over the last few years.
It may be an ecosystem problem but I think the big projects have an obligation to set the tone for what is acceptable elsewhere and not just jump on the next wizbang thing that’s marginally better or more correct.
Pros and cons but I see the cost of maintenance being very high in client side js compared to backend.
It may be an ecosystem problem but I think the big projects have an obligation to set the tone for what is acceptable elsewhere and not just jump on the next wizbang thing that’s marginally better or more correct.
Pros and cons but I see the cost of maintenance being very high in client side js compared to backend.
Fair.
The frontend ecosystem is definitely less mature than backend. Gmail and Google Maps, two of the first "real" client-side applications, were launched in 2004 and 2005 – so the entire ecosystem is really about a dozen years old. Before that people didn’t really “realize” that JS and web was a real programming environment. That means there's a lot to catch up on and a lot to experiment with as people figure out the best ways to build things. Compare this to backend or infrastructure development which have had decades to develop.
That said – I completely recognize that this can be painful. You don't always need to use the latest stuff though. If a "less fashionable" technology does the job for you, you can definitely use it. And trying to mitigate some of this complexity is why my team works on projects like Create React App which (whether or not you're using React) can insulate you from some of the "churn" that people often feel in the ecosystem.
In React itself, we try to have as few breaking changes as possible. (And our team needs to keep 50,000 components at Facebook working through our changes, which is a major incentive to not break things unnecessarily.) Our last major release, React 16, was released in Sep 2017. But it actually included almost no breakages (we mostly bumped the version number out of caution because it included a huge number of internal refactors). So I'd say our last "actually breaking" release was React 15, in Apr 2016, about 2.5 years ago. React 17 will probably be released sometime next year, so we're talking 3-ish years between releases. I think it's hard to do much better than that without stopping forward progress. Note that if we don't improve React quickly enough people will abandon it for another (incompatible) library, which doesn't really solve your problem either. So we try our best to make sure we're working on (what we think are) the right things and do our best to get it right the first time.
The frontend ecosystem is definitely less mature than backend. Gmail and Google Maps, two of the first "real" client-side applications, were launched in 2004 and 2005 – so the entire ecosystem is really about a dozen years old. Before that people didn’t really “realize” that JS and web was a real programming environment. That means there's a lot to catch up on and a lot to experiment with as people figure out the best ways to build things. Compare this to backend or infrastructure development which have had decades to develop.
That said – I completely recognize that this can be painful. You don't always need to use the latest stuff though. If a "less fashionable" technology does the job for you, you can definitely use it. And trying to mitigate some of this complexity is why my team works on projects like Create React App which (whether or not you're using React) can insulate you from some of the "churn" that people often feel in the ecosystem.
In React itself, we try to have as few breaking changes as possible. (And our team needs to keep 50,000 components at Facebook working through our changes, which is a major incentive to not break things unnecessarily.) Our last major release, React 16, was released in Sep 2017. But it actually included almost no breakages (we mostly bumped the version number out of caution because it included a huge number of internal refactors). So I'd say our last "actually breaking" release was React 15, in Apr 2016, about 2.5 years ago. React 17 will probably be released sometime next year, so we're talking 3-ish years between releases. I think it's hard to do much better than that without stopping forward progress. Note that if we don't improve React quickly enough people will abandon it for another (incompatible) library, which doesn't really solve your problem either. So we try our best to make sure we're working on (what we think are) the right things and do our best to get it right the first time.
At this point, I'm quite satisfied with React and use it for most of my new JavaScript UIs. A few potential improvements that come to mind:
1. More strictness in terms of what is and is not valid JSX. Just today I was working on a React Native app that compiled for iOS but not Android. The issue ended up being a stray semicolon, leading to syntactically incorrect code that allowed for a valid iOS build anyway. I would expect it to fail regardless of environment. The error was also very cryptic although this probably has more to do with React Native than React [1].
2. More proactive warnings at runtime for development builds. React does a great job at telling me what I'm doing wrong; I'd also like it to tell me what I could be doing better. Some ideas are cyclomatic complexity warnings to detect when there is too much branching logic in a component or warnings that indicate that a component is getting too large and could be refactored.
3. Rebuilding the virtual DOM in WebAssembly. Now this might be excessive as React performs quite well in my experience. But it could lead to performance and portability benefits as well as just be a cool project to work on. Mozilla published an article today regarding gains in JS and WebAssembly interop performance; check it out if you haven't [2].
[1] https://github.com/facebook/react-native/issues/13243
[2] https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
1. More strictness in terms of what is and is not valid JSX. Just today I was working on a React Native app that compiled for iOS but not Android. The issue ended up being a stray semicolon, leading to syntactically incorrect code that allowed for a valid iOS build anyway. I would expect it to fail regardless of environment. The error was also very cryptic although this probably has more to do with React Native than React [1].
2. More proactive warnings at runtime for development builds. React does a great job at telling me what I'm doing wrong; I'd also like it to tell me what I could be doing better. Some ideas are cyclomatic complexity warnings to detect when there is too much branching logic in a component or warnings that indicate that a component is getting too large and could be refactored.
3. Rebuilding the virtual DOM in WebAssembly. Now this might be excessive as React performs quite well in my experience. But it could lead to performance and portability benefits as well as just be a cool project to work on. Mozilla published an article today regarding gains in JS and WebAssembly interop performance; check it out if you haven't [2].
[1] https://github.com/facebook/react-native/issues/13243
[2] https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
Glad to hear React is working well for you!
Warning for things that aren’t errors seems like a slippery slope and one where false positives could be very annoying, but it’s an interesting request. For the specific problem of large, confusing components, we have some ideas about how to help make these more manageable that you’ll hopefully hear about soon.
React implemented in WASM is also a fun possibility but not one that we’ve started on yet. :)
Warning for things that aren’t errors seems like a slippery slope and one where false positives could be very annoying, but it’s an interesting request. For the specific problem of large, confusing components, we have some ideas about how to help make these more manageable that you’ll hopefully hear about soon.
React implemented in WASM is also a fun possibility but not one that we’ve started on yet. :)
Lin Clark did a talk last year where she discussed how React could _theoretically_ make use of WebAssembly, and how much benefit there was likely to be:
https://www.youtube.com/watch?v=3GHJ4cbxsVQ
https://www.youtube.com/watch?v=3GHJ4cbxsVQ
Have a look at reason-react, the compiler will find all syntax errors
Maybe this is either an uncommon use case or I'm missing an easy way to do it, but when you have a component tree like A->B->C (-> denoting child relation) and A contains most of the state and B contains many (say > 1k) children, and you keep updating state in A which only affects one or a few of C, the diffing process as I understand will check all of C whether they need to be rerendered. So if you update the state super frequently, let's say on mouse movement, you are doing at least O(C) checks just to update one or so C components.
So maybe you can pass forward refs from A to all the C's and then bypass B in the cases you want to directly trigger rerender on the individual affected C components. Is that the way to handle this scenario?
It's pretty late so the above maybe doesn't make sense, but to try to summarize, having a solution for updating deeply nested children without diffing all of the related components to see if they need rerender.
So maybe you can pass forward refs from A to all the C's and then bypass B in the cases you want to directly trigger rerender on the individual affected C components. Is that the way to handle this scenario?
It's pretty late so the above maybe doesn't make sense, but to try to summarize, having a solution for updating deeply nested children without diffing all of the related components to see if they need rerender.
Forgive me if I misunderstand the problem, but is it not sufficient to implement a fast shouldComponentUpdate on C, ideally making C a pure component? The render pass will still do a check for every C whenever B updates, but I would think that strict equality checks would usually be fast enough even for thousands of components every animation frame.
If that’s not fast enough, perhaps it would be faster to directly subscribe each instance of C to its state updates with something like Redux’ connect HOC. I assume that React does something like marking branches of the component tree as dirty and only doing a render pass on the dirty sections, but I could be wrong. If I’m correct, that would give you direct rerenders of the individual deeply nested C instances without rerendering A or B or unchanged C components at all.
If that’s not fast enough, perhaps it would be faster to directly subscribe each instance of C to its state updates with something like Redux’ connect HOC. I assume that React does something like marking branches of the component tree as dirty and only doing a render pass on the dirty sections, but I could be wrong. If I’m correct, that would give you direct rerenders of the individual deeply nested C instances without rerendering A or B or unchanged C components at all.
Thank you and @hfourm, I will try out the redux solutions proposed.
If you are in the Redux world I would maybe take a look at Reselect (https://github.com/reduxjs/reselect). As the other comment said, your problem should be solved by shouldComponentUpdate or more granular coupling of state to the component (or a combination).
I don't have any feature requests, I just want to say thank you to you and your team for making such a great platform for UI development. The ecosystem could certainly stand some improvement but react itself is fantastic.
I'm not sure if React Native (I haven't done much with React on web pages) is on topic here but I would say without any hesitation authentication.
React Native is so good and so similar to front end web work (including integrating native libraries, it was downright joyful once I figured it out) that the experience of setting up the most basic email/password authentication scheme really stood out. This is true to some extent throughout the native landscape (that it's a little more complicated than web pages), but still.
I think some might argue that this belongs in an external library, and maybe so, but I think there needs to be an easy to use standard library or framework component that keeps in mind what the developer experience is on the web.
React Native is still my first choice for a small-medium native app project, a good authentication story would put it on another level. Also note the last time this came up for me was a year ago so maybe there has been improvement.
React Native is so good and so similar to front end web work (including integrating native libraries, it was downright joyful once I figured it out) that the experience of setting up the most basic email/password authentication scheme really stood out. This is true to some extent throughout the native landscape (that it's a little more complicated than web pages), but still.
I think some might argue that this belongs in an external library, and maybe so, but I think there needs to be an easy to use standard library or framework component that keeps in mind what the developer experience is on the web.
React Native is still my first choice for a small-medium native app project, a good authentication story would put it on another level. Also note the last time this came up for me was a year ago so maybe there has been improvement.
Extract jsx into a separate template language not some halfways js compatible cludge. I don’t write php for a reason.
Deal with state better, currently if you have anything more than a list of todos, react grinds to a halt. It’s completely unable to deal with a realistic amount of state. Side note: this is really weird since react is very fond of state. I’ve tried redux and it just makes everything worse by adding in more checks that can only handle identity checks with any sort of efficiency.
Lastly react prevents me using a lot of existing js because it interferes with the lifecycle in react, or manipulates the dom directly. This makes working with react much less efficient than writing plain js.
Deal with state better, currently if you have anything more than a list of todos, react grinds to a halt. It’s completely unable to deal with a realistic amount of state. Side note: this is really weird since react is very fond of state. I’ve tried redux and it just makes everything worse by adding in more checks that can only handle identity checks with any sort of efficiency.
Lastly react prevents me using a lot of existing js because it interferes with the lifecycle in react, or manipulates the dom directly. This makes working with react much less efficient than writing plain js.
I do not have any particular request for the team. At office we love react and the journey of porting legacy to it has been enjoyable.
One thing that is somehow frustrating with multiple repositories are those shared components.
I know this is not directly an issue with react itself but after create-react-app one, two, three. ... times the amount of duplicated code/components become a huge debt.
I'm not sure I need something new/different from react@next but guidelines for creating libraries and produce high quality components (type definition done right for example) is something that I'd like to have.
One thing that is somehow frustrating with multiple repositories are those shared components.
I know this is not directly an issue with react itself but after create-react-app one, two, three. ... times the amount of duplicated code/components become a huge debt.
I'm not sure I need something new/different from react@next but guidelines for creating libraries and produce high quality components (type definition done right for example) is something that I'd like to have.
Disclaimer: I don't write much ui code. Random ideas:
-Simple constraint thing for when ui code+network latency+button mashing people fuse together in an explosion of corner cases.
-Frontend analyzer thing that tells you interesting things about your app.
-Make the declarative concept even more prominent w/code totally removed from the component in normal use case scenarios. Then the fancy tool explains how events & coroutines and so on interact. So swapping component libs becomes trivial.
-Simple constraint thing for when ui code+network latency+button mashing people fuse together in an explosion of corner cases.
-Frontend analyzer thing that tells you interesting things about your app.
-Make the declarative concept even more prominent w/code totally removed from the component in normal use case scenarios. Then the fancy tool explains how events & coroutines and so on interact. So swapping component libs becomes trivial.
Do you actually work on the React code base or are you part of the marketing team behind React? Tried it, I'm amazed at the hype you guys throw behind this simple framework, looking for more things to steal/hype, facebook?
Go ahead keep working on it, but take the hype out. Let people decide on their framework without having to stumble upon a PR piece for React. No reason this project needs so much weight thrown behind it.
Go ahead keep working on it, but take the hype out. Let people decide on their framework without having to stumble upon a PR piece for React. No reason this project needs so much weight thrown behind it.
Can you help me understand what hype you mean? We don’t pay anyone to promote React. And everyone from Facebook you hear speaking about React is likely an engineer working in or on React, or an engineering manager for the same.
(Yes, I manage the team that builds React.)
(Yes, I manage the team that builds React.)
I mean the guy who comes to your defense here also works on React. I don't think Google makes posts on Hacker News soliciting feedback on Angular and then has their devs start astroturfing the thread. It kind of proves my point. If you guys think this is the venue to get technical feedback, it shows that you guys don't know what you're doing, but I'm sure you do, because it's PR.
I'd bet posts like this got flagged by someone who works on React - https://news.ycombinator.com/item?id=12284926.
React is nothing revolutionary, but you wouldn't know that from the PR apparatus that is facebook, and some people should be rightly concerned about facebook's motivations when the company seems to prize market share above all else. This post seems to fit in that puzzle for me.
I don't know if HN has the same attitude towards 'shilling' as reddit does - but I feel like the FB dev team is guilty of this offense from time to time.
I'd bet posts like this got flagged by someone who works on React - https://news.ycombinator.com/item?id=12284926.
React is nothing revolutionary, but you wouldn't know that from the PR apparatus that is facebook, and some people should be rightly concerned about facebook's motivations when the company seems to prize market share above all else. This post seems to fit in that puzzle for me.
I don't know if HN has the same attitude towards 'shilling' as reddit does - but I feel like the FB dev team is guilty of this offense from time to time.
I figured HN would be a suitable venue to get technical feedback from a broad audience because the communities I spend the most time in are skewed towards people who use React heavily, and HN felt like a "fairer" sample of devs including both ones who use React and ones who might have tried React and then abandoned it. I'm not actually sure where you think a post would be more effective.
The ~100 points this post has are also not from people who work on React (seeing as there's less than 10 of us). This indicates to me that people here do find this post interesting.
The post you linked also have dozens of comments from people explaining ways it is inaccurate. It's probably those people who flagged it, not us. (This is my first time seeing that post.)
I don't think we're tricking anyone into using React and I think we're always honest about who we are, but I'm sorry that our comments have come off as "shilling" and "astroturfing" to you. It's not why we're here.
The ~100 points this post has are also not from people who work on React (seeing as there's less than 10 of us). This indicates to me that people here do find this post interesting.
The post you linked also have dozens of comments from people explaining ways it is inaccurate. It's probably those people who flagged it, not us. (This is my first time seeing that post.)
I don't think we're tricking anyone into using React and I think we're always honest about who we are, but I'm sorry that our comments have come off as "shilling" and "astroturfing" to you. It's not why we're here.
(By the way Sophie isn’t only managing the team but also one of the first open source contributors to React and one of the top three committers to it over five years.)
One thing I miss is Vue like v-bind directives that sync with a property on the state. I hate writing a function just to sync the current value with the state.
Hi, I decided not to use React when I learned about JSX and CSS in JS.
People (developers who use React) keep telling me it's not true that JSX and CSS in JS make you write the worst possible HTML.
I keep seeing them writing things like <span><h1><span>my title</span></h1></span>.
People (developers who use React) keep telling me it's not true that JSX and CSS in JS make you write the worst possible HTML.
I keep seeing them writing things like <span><h1><span>my title</span></h1></span>.
> I keep seeing them writing things like <span><h1><span>my title</span></h1></span>.
React doesn’t care what HTML tags you render. If you see people using bad markup, perhaps that’s an opportunity for them to learn. It doesn’t sound like a React problem – if there’s anything on our site or in our docs that suggests otherwise, please let me know.
React doesn’t care what HTML tags you render. If you see people using bad markup, perhaps that’s an opportunity for them to learn. It doesn’t sound like a React problem – if there’s anything on our site or in our docs that suggests otherwise, please let me know.
Some other comments also touched on this, styling remains my biggest pain using react (I made or worked on a dozen react projects of varied sizes).
I wish for media queries and keyframes (and other CSS tidbits) to be possible in React JS styles, so that I stop hopping between different CSS module libraries.
I wish for media queries and keyframes (and other CSS tidbits) to be possible in React JS styles, so that I stop hopping between different CSS module libraries.
[deleted]
More documentation around the effect of specifying / not specifying key prop would be extremely useful to ensure people understand how it affects lifecycle methods.
In fact more documentation around practical patterns would be useful.
In fact more documentation around practical patterns would be useful.
bring back 2-way binding. There are use cases, where it greatly improves productivity. Leave the choice about it to the developer.
I wonder if this could be solved with a general jsx decorators feature? For example:
<input @bind("username") name="username" />
there are various ways to put this into a syntax.
one way would be to have a dedicated attribute that behaves this way for relevant components.
This would then be similar to the vue.js approach https://vuejs.org/v2/guide/forms.html
<input model={myJsObject.text} /> or <input bindValue={myJsObject.text} />
At least for standard HTML components this should work, as they would only have one editable property.
<input model={myJsObject.text} /> or <input bindValue={myJsObject.text} />
At least for standard HTML components this should work, as they would only have one editable property.
Eliminate manual typing of PropTypes.
Just completed a chapter on PropTypes. While useful, they seem to be an excessive and tedious. Can't we somehow leverage TypeScript for the model validation instead?
TypeScript, Flow, and ReasonReact all support defining types for props. React PropTypes are completely optional and only give warnings in development, so I you’re using a language or language extension with compile-time type-checking you shouldn’t need PropTypes.
Built-in shims and css handeling for old/weird/mobile browsers. This would be great!
My vote is for a standardized cross platform navigation library to ship with react native.
as long as facebook owns it and controls the licensing I will be using Vue over react.
Is there a particular concern you have? React is MIT licensed (same as Vue), and there's no way for Facebook to take back that license from you.
(React could stop being developed, as could Vue. In both cases, you or anyone else could pick it up and build upon the last version.)
(React could stop being developed, as could Vue. In both cases, you or anyone else could pick it up and build upon the last version.)
I don't trust facebook period.
they can still relicense it in the future if they manage to kill off their competition. At that point I'd have to hope that someone will fork a pre license change version. Don't want to risk dealing with that crap don't want to support facebook.
they can still relicense it in the future if they manage to kill off their competition. At that point I'd have to hope that someone will fork a pre license change version. Don't want to risk dealing with that crap don't want to support facebook.
CRA typescript
be more like Vue
Anything in particular you think Vue does better? We'd love to improve.
Styles.
I know Facebook has an internal CSS Module thing that is not open source ready. So this has been pushed off to user land. However, lack of an officially blessed style solution makes React components less reusable across projects compared to Vue. Thanks to vue-loader, the Vue community can focus on other things. I am NOT advocating for single file components like Vue, I am hoping that FB can just bless a solution so we can move forward as community.
I know Facebook has an internal CSS Module thing that is not open source ready. So this has been pushed off to user land. However, lack of an officially blessed style solution makes React components less reusable across projects compared to Vue. Thanks to vue-loader, the Vue community can focus on other things. I am NOT advocating for single file components like Vue, I am hoping that FB can just bless a solution so we can move forward as community.
I agree styles are an afterthought in React. I'm starting to grow fond of Styled Components, but even then I still find doing more advanced CSS operations a bit of a pain. Things like global styles, media-queries, pseudo-selectors and nested selectors sometimes require a pretty good understanding of the library's API and almost always require a trip to the documentation.
I'm really quite pleased Vue sort applied the component approach to styles by slapping them in the component file and then left it at that.
I'm really quite pleased Vue sort applied the component approach to styles by slapping them in the component file and then left it at that.
[deleted]
I actually found a bug last week with React's styling logic. I haven't submitted a bug report yet because, well, I'm lazy.
But if OP reads this comment, I outlined it here:
https://stackoverflow.com/questions/52636618/modifying-react...
But if OP reads this comment, I outlined it here:
https://stackoverflow.com/questions/52636618/modifying-react...
God, this is one of my pet peeve issues. I swear we'll fix it someday.
https://github.com/facebook/react/issues/6348
https://github.com/facebook/react/issues/6348
Ha! Glad that it's known, at least.
I do love Vue's single file components for small components. It's a big productivity boost to be able to reason about the different facets of a component together.
I recognize that it's a very different philosophy, but first-class support for interpolated HTML made porting existing applications very easy in Vue.
Make the world better by making something else new and better.
Decide what it wants to be and what its endgame is.
Currently it's a DOM management library that runs like a in-browser plugin, basically hijacking the browser, with tendencies to be a cross-platform native tool.
Realistically, it's a bloated view layer with a huge runtime (React + React DOM are ~100k minified).
While performance on iOS is good, the Android experience is horribly slow and full of bugs. What people like about it is the yoga layout engine primarily.
So basically you have a 100k runtime at minimum + a questionably maintainable, and definetly not a reusable native aspect of it.
Currently it's a DOM management library that runs like a in-browser plugin, basically hijacking the browser, with tendencies to be a cross-platform native tool.
Realistically, it's a bloated view layer with a huge runtime (React + React DOM are ~100k minified).
While performance on iOS is good, the Android experience is horribly slow and full of bugs. What people like about it is the yoga layout engine primarily.
So basically you have a 100k runtime at minimum + a questionably maintainable, and definetly not a reusable native aspect of it.
Whether you use React now, tried it in the past, or decided not to try it – what could make React better for you?