Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I wish I knew about React

bitsofco.de

Post reply on HN
Print view View original

281–290 of 301 posts

Re: What I wish I knew about React

#281

Post by mikewhy »

ng12 wrote: post #244
mikewhy wrote: post #236

Earlier quoted context omitted.

Can you clarify on that last point a bit? Not that I extend React.Component these days, but far as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended. I guess, yes, there's different semantics between the constructor and componentDidMount, but it's UI library, this is common that "when a constructor is call there is no guarantee the component has actually mount…

Sure, what I mean is you'd never use a React.Component like you would a class in Java or another OO language. You never instantiate it, pass instances of it around, or call any of its public methods. It serves just as a container for some functions and provides a binding for `this`. Dealing with `this` caused things like componentWillRecieveProps to be buggy so hooks allow you to use a function as the container and r…

You can definitely pass them around and call public methods on them using refs, that's what useImperativeHandle is mimicking.

Was the issue with `this` in componentWillRecieveProps not solved by using an arrow function? If so, that just sounds like normal JS binding woes.

Re: What I wish I knew about React

#282

Post by fit2rule »

wtmt wrote: post #239
fit2rule wrote: post #136

Earlier quoted context omitted.

http://lobste.rs is a good starting point. Not as much hate there..

Related question: Does it still require hanging around and waiting for an invite to create an account? If yes, then I’m not going to try again and waste my time.

Its not hard to get an invite. I'd invite you if I knew your address.

I consider this a slight inconvenience but still a better system than having the dang hammer around to pound spammers ..

Re: What I wish I knew about React

#283

Post by azangru »

sngz wrote: post #280
azangru wrote: post #276

Earlier quoted context omitted.

> So the issue I'm referring to is this, which has been open since 2017 I probably don't appreciate the complexity of the issue, but I would say environment variables are not React's concern; it’s up to you how to architect your code. If you want runtime environment variables, then either add them to the html that React will render into, so that the javascript code can read these variables in before rendering, or hav…

> but I would say environment variables are not React's concern; it’s up to you how to architect your code I don't consider it part of the "code" but part of configuring the application based on the environment you're deploying it on(Precisely why the FE dev basically said its not his problem). The fact that a lot of people are suggesting you just build the app every time you deploy a docker container is really conce…

Dotenv runs on the server. If a part of your application also runs on the server (such as with Next, Nuxt, etc.), and your responses are generated dynamically, then it is trivial to use the dotenv. If, however, the runtime of your application is confined entirely to the browser, and what you are serving to the browser is only static assets, such as with create-react-app, then, if you still want your environment variables to be defined at runtime rather than at build time, you need to design a bridge between your server and your client specifically for injecting the environment variables.

Here, for example, is an article describing such an injection at the nginx level: https://medium.com/@jans.tuomi/how-to-use-environment-variab.... Or you can serve index.html using a full-fledged dynamic server, such as Node, and inject environment variables there (and probably cache the response for good measure as well, not to overstrain Node). This really is not something that is React’s responsibility — although it may very well be the responsibility of the frontend developer to set this all up.

Re: What I wish I knew about React

#284

Post by karolsputo »

chadcmulligan wrote: post #137
ggregoire wrote: post #95

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

Its reaching the point where it is becoming standardised, and therefore not interesting, and so it must pass, and a new framework will become the one to use for web development. It's axiomatic that web development must be cool and new and therefore no framework can ever become a standard.

I see a lot of pro-Svelte comments/entries on HN. It seems to be endorsed stronger than the mainstream, big libraries right now

Re: What I wish I knew about React

#285

Post by jaeyson »

sjwright wrote: post #207
chadcmulligan wrote: post #137

Earlier quoted context omitted.

Its reaching the point where it is becoming standardised, and therefore not interesting, and so it must pass, and a new framework will become the one to use for web development. It's axiomatic that web development must be cool and new and therefore no framework can ever become a standard.

I still write web in ColdFusion and (mostly) plain JavaScript. Seriously. I’m not cool at all.

I'd still say cool tho.

Re: What I wish I knew about React

#286

Post by capableweb »

snarfy wrote: post #197
capableweb wrote: post #58

Earlier quoted context omitted.

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as bo…

> I've always found the best distinction between a framework and the library lies in who-calls-who? I've heard this referred as the 'Hollywood principle', as in 'Don't call us, we'll call you'.

Hm, I'd say in a framework you usually work with the Hollywood principle, but when using something like a library, you're not. So you're 50% correct :)

Re: What I wish I knew about React

#287

Post by iainmerrick »

LinguaBrowse wrote: post #257
partyboat1586 wrote: post #251

Earlier quoted context omitted.

The JS is run in a separate thread because the real-time operations are meant to be handled fully native. If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. You can't code it like a web app where you just replace one large node tree with another if you want it to be instant, y…

> If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. I’m working on an alternative to React Native that does exactly this, and it works absolutely fine: React NativeScript. In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI threa…

Sounds great! After using RN for a while, that’s exactly how I think it should have been designed in the first place. Good luck!

Re: What I wish I knew about React

#288

Post by mercer »

karolsputo wrote: post #284
chadcmulligan wrote: post #137

Earlier quoted context omitted.

Its reaching the point where it is becoming standardised, and therefore not interesting, and so it must pass, and a new framework will become the one to use for web development. It's axiomatic that web development must be cool and new and therefore no framework can ever become a standard.

I see a lot of pro-Svelte comments/entries on HN. It seems to be endorsed stronger than the mainstream, big libraries right now

My impression is that for a lot of developers on HN, a kind of front-end fatigue has grown stronger and stronger. And as a result, there's a preference for various solutions that reduce the amount of 'dynamic javascript' work required.

While I'm not particularly hostile to javascript or React myself, I do notice that over time, I tend to avoid it whenever I can. It wasn't too long ago that I made (gentle) fun of Intercooler.js (what happened to that person and their tireless efforts to insert it into any vaguely relevant conversation?), for example.

But nowadays, I'm fully on the Phoenix LiveView bandwagon (React/js on the server!), and I would absolutely use Svelte or Intercooler if LiveView wasn't an option, I grumble whenever I need to deal with my js pipeline (Webpack, PostCSS, etc.), and whenever I do need to deal with it, I get an almost existential 'where did things go wrong' feeling. Maybe I'm just getting old, in front-end developer terms anyways.

All I know is that for the past year I've barely kept up to date on the latest in React (Hooks?!), CSS (grids? flexbox?), js bundlers, browser features (webworkers? the latest in LocalStorage? webcomponents?), and so on, and instead I've been dealing with databases, servers (nginx, linux, etc.), and other 'back-end' things instead.

I feel much, much less frustration because suddenly things stop working and I need to dive into the complex world of webpack and its loaders, CSS and it's various browser incompatibilities, and so on. But I also feel that the things I /do/ learn will probably be valuable for years to come.

The insane amount of stuff I've learned about jQuery is practically worthless now. The same goes for Bootstrap and Backbone.js. Or various CSS layout tricks (dear god the floats). But what I'm learning about Postgres and Ngix and Railsy back-ends seems like the kind of stuff I'll be able to use (and make a living off) for a long time to come.

I do really like TypeScript though. I'd love to use that more :).

Re: What I wish I knew about React

#289

Post by mercer »

tenaciousDaniel wrote: post #184
ggregoire wrote: post #95

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

I've been considering the jump into TS, but I don't want to end up in a coffeescript situation (i.e. language is dead, but code lingers on and has to be converted back to JS at some point, rather painfully). Do you think it's worth it?

I've been doing less and less JS stuff, but I actually miss TS at times. I think it won't end up like CoffeeScript, and it's absolutely worth using if you need to write javascript!

Re: What I wish I knew about React

#290

Post by doublerabbit »

aylmao wrote: post #148
pjmlp wrote: post #63

The more I read about React, the happier I am to use VanilaJS alongside SSR and web components friendly frameworks.

You should try to use it too! If you discover you don't like anything about it, all the better, you can say you've experienced it and not just read about it. If you happen to like at least parts of it, you've just expanded your knowledge and arsenal of tools for UI development.

I just can't get myself around to use anything by FANG just due to their licenses.

Using a framework means your project will never purely be yours.

React license:

> The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.

Post reply on HN