What is Reddit's opinion of
React?
From 3.5 billion Reddit comments
➔ React website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
Pages will be loaded in the background when you hover over a link. That data will subsequently be cached. I do the same thing for one of my clients' websites and it works really well. When a user searches something in the main search box, the first autosuggested item's data will be loaded in the background.
Edit: I just checked and it seems like in reactjs.org's case, they seem to start preloading any content that's in the viewport as soon as the DOM has finished loading by using the Intersection Observer API. This is done by Gatsby.
(thanks to the Gatsby founder for pointing this out on Twitter lol)
React is essentially a way to update the view. The view initiates an action (a button press) which updates the state (active=true) which then updates the view (div becomes red).
I've had two problems learning: componentization and logic placement.
- Componentization is tough because you want to write less code/modules so you think "This isnt that complicated, I'll just stick it all in one component," and then the rake hits you.
- Logic placement can be really tough. You can get things to work by putting the logic wherever (even in your components), but then you get hit by a rake. Once you get good enough you can do kickflips through middleware and then get hit in the face by a messed up state structure.
Edit: React doesn't have many pitfalls and it's actually very simple. (just be wary of ref's) There are a few concepts you need to understand though like reconciliation, lifecycle, immutability, and (eventually) higher order components. I recommend React. It's a really cool idea.
Yep, you can watch the network tab in dev tools to see it making calls to get a json file like this:
The response is a data object containing markdown that gets rendered out as the content so there's virtually no delay when navigating between pages on their site. Definitely a nice way to reduce your perceived load times.
There is a section in react docs explaining the motivation behind the hooks.
Hooks are not just replacement for class components lifecycle. It's a way of solving a problem. The problem of reusing stateful logic between components. With class components, we were solving this problem using render-props and higher order components, which was far from ideal.
>To some degree, I think Redux is somewhat to blame, with each object needing global state being wrapped in a Connect component. As such, inspecting a React tree is often nearly twice as long than it feels like it needs to be.
This is called "Wrapper Hell". We all have felt that pain.
> It’s also not always clear where the data is coming from that is populating a component. Sometimes it’s five levels up being passed down through rested props.
This is called props drilling. You're giving me the impression this codebase was a little gnarly.
>I’ve often found myself hopping on a call with a co-worker, someone who has been with the company and the code much longer than I have, to be told, “yup, that should probably be refactored.”
There ya have it folks. If you don't keep your code clean, it will be very painful to onboard new talent, even very patient, new talent. Ideally React components will allow you to take things one at a time, but honestly since components provide you so much freedom, there's plenty of ways to write in patterns that create a rats' nest very fast. Even Redux can't save you then. OP, it's important to recognize the changes you can make, but also the difficulties that did not originate with you.
State updates maybe Asynchronous
Following your example above, setState(state + 5) will just add 5 to state, but we know that setState is actually asynchronous and is sometimes batched together with other setState calls by React to boost performance.
if we had multiple setState(state + 5) calls, and they got batched together, state won't change until the whole batch is finished. So if lets say state is 10, the result would be:
setState(10 + 5) setState(10 + 5) setState(10 + 5)
Instead of adding 15 to our state it would only add 5 in the end. That's where we want to pass an anonymous function.
setState(current => current + 5)
If we call this multiple times and they got batched together...
setState(current => current + 5) // current is 10, we return 15 setState(current => current + 5) // current is 15, we return 20 setState(current => current + 5) // current is 20, we return 25
We would have added 15 to our state, even when it was batched.
Components can be really simple, especially with functional components. These can really simplify the code and make the user interface more consistent across the application. However, I have to agree with you that using existing Bootstrap classes or React-Bootstrap might be a better solution here.
Yes, you should prefer using function components for everything today. Class components still work, but you really shouldn't be writing any new class components.
FYI, the React team has been working on a complete rewrite of the docs to teach function components + hooks as the standard approach for writing React components. Those should hopefully be going live fairly soon.
For more details, see:
From the docs:
>We intend for Hooks to cover all existing use cases for classes, but we will keep supporting class components for the foreseeable future. At Facebook, we have tens of thousands of components written as classes, and we have absolutely no plans to rewrite them. Instead, we are starting to use Hooks in the new code side by side with classes.
I guess it doesn't. However, there are other ways to determine whether you should preload content. Say if the click rate for that link is 95% or if the link is to the next part of a tutorial, then it's probably worth doing. Basically predicting what the user is going to do. You do have to watch out that the content you're loading isn't too big though, as mobile users don't want to waste their data.
Edit: I was wrong. reactjs.org uses Gatsby which apparently preloads anything that's in the viewport
No. Class components still work, but function components and hooks are now the standard approach used by the React community for any new code, and there are some new React features that only work with hooks.
The official React docs are the best resource for learning hooks:
https://reactjs.org/docs/hooks-intro.html
Unfortunately, the React docs still teach classes in the tutorials. A rewrite is in progress (and hopefully will be in preview sometime soon), but until then, there's a "React with Hooks" version of the React docs that uses hooks and function components for all examples:
https://reactwithhooks.netlify.app/
This article explains why hooks are important and what problems they solve:
The second part that is commented out is the correct usage, you just have the wrong type. React has a wrapper around the native event types, https://reactjs.org/docs/events.html, so you just need to change Event to the corresponding react synthetic event type.
Facebook doesn’t recommend rewriting classed based components. I usually don’t either unless I am fixing bugs in an existing component or adding additional functionality. See here https://reactjs.org/docs/hooks-faq.html#should-i-use-hooks-classes-or-a-mix-of-both
It's interesting because it really seems highly personal. People come up with lots of logic about why they like one or the other but a lot of it seems like ex post facto rationalisation. I think it's actually very subjective. Personally, I like Vue because it just seems nicer. I sit down to write it and it works kind of they way my brain says things should work.
To make that more concrete, if I go to do something 9 times out of 10 the way to do it is intuitive and makes sense with how I would like to do it if given a choice. Compare to React about 50% of the time I go to do something and it works different to how I expect and I read a whole lot of tutorials 'teaching' me why it's better to do it this way I don't really like, and if I sort of push through that everything is just fine, but I'm still left with these questions lingering doubts, if I couldn't have just done it the intuitive way.
But clearly about half the population have exactly the opposite intuitions and experience!
NB: for an example, this is the kind of thing
https://reactjs.org/docs/faq-state.html#why-is-setstate-giving-me-the-wrong-value
where you are left thinking "really, can't the framework just work how I expect?" and Vue does.
edit: link to correct section
What is the point of these articles? The same exact topics get rewritten and reposted seemingly several times a week. But somehow, the official docs are still the best and most comprehensive source of information.
>...This approach enables the declarative API of React: You tell React what state you want the UI to be in, and it makes sure the DOM matches that state. This abstracts out the attribute manipulation, event handling, and manual DOM updating that you would otherwise have to use to build your app.
React Docs - Virtual DOM and Internals
Describing the desired state of UI is the declarative approach.
Manually updating DOM step by step to reach the desired state of UI is the imperative approach.
I don't want to be mean. This project looks like something one person can manage alone, but not someone who needs to ask about Flask vs Django.
If you choose this path, you may need Python, but also some JavaScript, HTML, CSS, a bit of servers...
If you want to start making money with this, I recommend you to start with serverless architectures, AWS (lambda, cognito, aurora...), React for FrontEnd, etc.
This is (and I will get angry replies for this) much flexible, robust and cheap than Django sitting in a server (I worked with Django for 4 years, so my opinion counts)
This is the option companies like Netflix and AirBnB uses, and Amazon, Alibaba and others are migrating to.
It's named that way on purpose.
> In general, setting HTML from code is risky because it’s easy to inadvertently expose your users to a cross-site scripting (XSS) attack. So, you can set HTML directly from React, but you have to type out dangerouslySetInnerHTML and pass an object with a __html key, to remind yourself that it’s dangerous.
React.forwardRef? I'll make it quick:
- You want to make a component and let the users to access its internal DOM node — to position popper, or
.focus()it, or whatever. - Your component can't accept a prop called
refand forward it as usual, becauserefandkeyare the two magic prop names React swallows and they're not in FC arguments or this.props. - On class components,
refprop implements a horrible feature that lets you obtain a class instance from the parent and call its methods — like a pre-hooks useImperativeHandle - The traditional workaround is to use a prop called innerRef / getRef / whateverRef, then have a
({ getRef }) => <div ref={getRef} /> - To unify the API, it's nice to pass
refon anything to get DOM node, not remember what the???Refname is. forwardReftells React not to swallow therefprop, and pass it as a second argument instead.- Class components are already lost because they do that older ref thing, and changing that would break many things, so only FC gets this feature.
Hope this clears things up!
Yes, the React core team discussed that in their blog post on the release candidate of v.17, and advised those who really need synchronous cleanup to use the useLayoutEffect.
Note that Photoshop uses a variant of JavaScript called ExtendScript, likely based on ES3/ES5. The .jsx extension refers to ExtendScript and not JSX.
JSX isn't HTML. A `<p>` tag in JSX isn't the same thing as a `<p>` tag in HTML and this demonstrates a little bit of a lack of understanding of what JSX actually is. In React, you aren't creating DOM elements or writing HTML yourself at all. You're issuing calls to `React.createElement`, which is what JSX is. It's syntactic sugar around calls to `React.createElement`. When you write JSX, you indicate the "type" which is another component or an HTML element, props, and children. They're just function arguments. In a web application, React handles the actual management of the virtual DOM elements, and the modification of the actual DOM via `react-dom`.
​
JSX isn't HTML, or an HTML replacement. It's a familiar syntax that was added to the framework because the alternative is having gross deeply nested calls to React.createElement all over your project. Feel free to use createElement instead of JSX if you want - it works just fine.
This will be worth a read: https://reactjs.org/docs/hooks-intro.html
They let you write all your React components as functional components, rather than as classes. They change the way your React components interface with their state and with their own lifecycle.
Erm... there's an entire page on how to do that:
https://reactjs.org/docs/hooks-custom.html
and it basically boils down to "cut code that calls some hooks from a component, write const useMyNewHook = () => {}, paste code inside".
In all seriousness, what do you feel the current docs page doesn't cover sufficiently about this?
Props and state are not interchangeable. Props are the API of your components, i.e. their public interface. State is private to the component.
In a React application you need some sort of state, and there are many solutions to this. However you do not get far with good coding practices, if you also do not use props.
It sounds like you may benefit from learning about pure components. Unfortunately I don't know what's the best up-to-date resource on this topic, as things have changed quite a lot since just a few years ago. Notably, class components are hardly used anymore.
Maybe the official Tutorial is a good place to start
You typically shouldn't bind or make new functions in the render method, if it can be avoided. This is so calling render doesn't have to make a bunch of new functions every time.
> We generally recommend binding in the constructor or using the class fields syntax, to avoid this sort of performance problem.
React is a library to create web apps. You'd use it to create single-page apps or UI which needs to change/update based on user input. It's strong points are that it's declarative (so the data is seperated from the view, you don't need to manually change the html/text of dom elements) and uses JSX, so looks a lot like HTML so is nice and familiar.
React Native is a entire toolchain to create native Android and iOS apps. The apps are written in Javascript and use React for layout. You'd use it to create cross-platform apps rather than learning to use the tools provided by Apple or Google for phone app development.
Redux is a data store. You'd use it in a single-page app to save data between page changes, or to fetch things from a database or to share data between different components. It's key points are that it's an event bus, so you pass it an object describing the event and some data, and the store updates; only one event can happen at once so it's easier to know exactly what's happening to your data at any point (ie nothing's going to change the data without you realising). It's a stand-alone library so can be used without React; if you want to use it with React then react-redux is a library which makes it easy to use the two together.
(Note: This is a very brief overview so I missed loads of details out!)
React is quite a nice library, and I found it much easier to use than Angular, so you may as well give it a go
> In my experience, API is more commonly used when talking about services whereas SDK is used to talk about libraries.
That would be an incorrect usage. An SDK is very different from an API.
> But fair enough, I can see how you might define a library’s methods, etc as an API
...it's not just me, it is defined as an API. That's what an API is. "Application programming interface". It's an interface to code. That code can be an external web server, it can be a library, it can be part of your own application.
In class-based OOP, your class has an API and it is defined as the public methods.
Here's React, calling it an API. Industry standard term, not just web servers.
>What's really needed is a way to duplicate the client-side rendering logic in the server, so the initial page is fully populated*, but the content is modified incrementally as the user interacts with the page.
You're thinking of server-side rendering. Lots of frameworks do this. Here's a solution for React. I'm fairly certain Angular and Vue are capable of this as well.
I've never been able to bring myself to like it. It's great for bridging the gap between designers and developers, but if I'm not in a project where I don't need to worry about that, I'll usually go the other route, and I'm a big fan of react-hyperscript in particular.
- Touché. It's not React's fault. And the React does recommend the use of static typing for large projects.
- I'm not sold on the CSS-in-JS just yet. I want to be. TypeStyle has piqued my interest. It seems harder to leverage the cascading part of CSS when using JS.
- I'll have to check out MobX
- The amount of indirection and mess to define types correctly seems greater when
propsandstateare not simply members of the component. - Right on!
- NgModules prescribe a certain amount (albeit loose) structure into the organization of the app. That, I think, is valuable.
- True. Then my team needs to stop doing this.
- True, but then again Angular encompasses a half dozen or more features whereas a React project would need an equal number of third-party dependencies and more points of failures. You could reasonably get by with an Angular app with only the packages included in the CLI scaffolded project, and perhaps Angular Material.
I think you need to save what you've been working on so far, close your editor and take a minute to read the React docs.
https://reactjs.org/docs/thinking-in-react.html
Everything you've mentioned is a lack of understanding of how React is supposed to work, and you're trying to fight against it using practices found in frameworks such as Angular and Vue.
Because you want to animate when components enter or leave the DOM you need to use ReactCSSTransitionGroup. You say you find their documentation confusing so I will try to explain what it does.
When a component enters or leaves the DOM, ReactCSSTransitionGroup adds a CSS class to it for the time it enters/leaves. This way you can style the animation during the time it enters/leaves. This is code from the docs:
<ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}>
{items} </ReactCSSTransitionGroup>
Items is a list of React components. Whenever something is added from items, it will add the class example-enter to that component. Whenever something is deleted from items, it will add the class example-leave to that component. Then you can style those classes. This is styling from the docs:
.example-enter { opacity: 0.01; }
.example-enter.example-enter-active { opacity: 1; transition: opacity 500ms ease-in; }
.example-leave { opacity: 1; }
.example-leave.example-leave-active { opacity: 0.01; transition: opacity 300ms ease-in; }
Does that clarify anything? If not, please ask again and I will try to improve my answer :)
https://reactjs.org/docs/hooks-effect.html#effects-with-cleanup
TLDR; The cleanup function is used to close subscriptions to external data sources or event listeners, to avoid memory leaks
The documentation shows that you can and should use useState and useEffect together, and there is absolutely no problem with that. You can use useMemo for expensive calculations, not for simple variable changes because it's just one more layer of code.
I would start with the official docs, there is a tic-tac-toe tutorial that was created as an intro to react. Material-ui is mostly a set of react components based off googles material design principles. Kinda like a fancy css framework.
> 2) Know Thy HTML: ... JSX is still HTML so be sure is valid HTML!
Well that's just wrong. JSX is definitely not HTML.
JSX is syntactic sugar for JS function calls.
The second page of the React docs introduction even says this:
> Since JSX is closer to JavaScript than to HTML, React DOM uses camelCase property naming convention instead of HTML attribute names.
We wrote a whole blog post about the legacy lifecycles (technically not deprecated yet) and the migration strategy for them.
https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html
Note it's also possible to keep using them (if you must) even in React 17, but you'll need to add an UNSAFE_ prefix to them. This can be done by an automated tool we also released.
Eu, por acaso, não sou grande fã do desempenho, falando em termos de velocidade, das aplicações web em React feitas na plataforma OutSystems. Sinceramente não sei se o problema é do React em si ou da forma como é usado pela plataforma.
​
Disclaimer: Eu trabalho na OutSystems, e no R&D ainda por cima.
simple really. you use cleanup functions. here's a simple example
useEffect(()=>{ let mounted = true; (async () => { const data = await requestData();
if (mounted) { setData(data) } })()
return () => { mounted = false } }, [])
https://reactjs.org/docs/hooks-effect.html#example-using-hooks-1
The hooks FAQ specifically answers that one:
https://reactjs.org/docs/hooks-faq.html#how-do-i-implement-getderivedstatefromprops
Also not sure what you're expecting them to "rethink". The APIs exist, and aren't going to change meaningfully at this point.
With the addition of Hooks, there are very few reasons for class-based components.
That’s also the recommendation of the React team: https://reactjs.org/docs/hooks-faq.html#should-i-use-hooks-classes-or-a-mix-of-both
This is a copy paste job from the react docs: https://reactjs.org/docs/refs-and-the-dom.html
In the article he states:
When Should I use Refs? We advise to use refs in the following situations:
Integrating with third-party DOM libraries. Triggering imperative animations. Managing focus, text selection, or media playback.
In react docs it states:
When to Use Refs There are a few good use cases for refs:
Managing focus, text selection, or media playback. Triggering imperative animations. Integrating with third-party DOM libraries.
A lot of Facebook's innovation has been more in terms of Software Engineering than anything else (for instance they created React JS). All of which is happening in their Engineering teams, which I doubt Zuckerberg has much involvement with any more.
I think he's a bit like Elon Musk, smart up until a point, but beyond that it's the people they employ who are really doing the heavy lifting.
I’m aware that you can do this but it doesn’t necessarily mean that you should do it.
The context is performance optimisation and that’s literally what useMemo is for.
You can argue and down vote all you want, it won’t change this fact.
Honestly the official intro resources are no longer recommendations in my eyes (with one exception). Instead, look to the resources on the sidebar of this subreddit, particularly Kent Dodds' course for beginners. He also explains why it was created and what problems it's solving.
Fundamentally, React asks you to shift your mentality towards components. This is reflected in almost every corner of react and why it does things the way that it does. That's where the one exception I have above comes in because the official site does break down the usual process of "componentization" through this link https://reactjs.org/docs/thinking-in-react.html. But again, this is so much easier to understand if you know javascript already.
Focus can easily be done using references.
class MyComponent extends React.Component { constructor(props) { super(props); this.myRef = React.createRef(); } componentDidMount() { this.myRef.current.focus(); } render() { return <input type="text" ref={this.myRef} />; } }
See the documentation for <code>import</code>.
Basically it will only import the <code>Component</code> class from React so you can use it in your code as Component. If you just import React, then you'd use React.Component.
Node.js can be used for backend.
Was there any other reason to bother learning Python? I'd imagine it's useful if you're going to do machine learning, or a lot of sysadmin scripting where you might find pip packages to be useful... but no need if you're mostly doing webdev... unless you happen to need to work on some existing Python project for an employer/client or something.
If you want to learn a bit more "programmer" stuff, and have some time for learning beyond plain JS, I'd highly recommend getting into TypeScript. Which you'll need to do to use Angular anyway. TypeScript is a great introduction into typing systems used in many other programming languages, and already knowing TypeScript really helped me when I started using other languages like C#, Rust, Haskell.
TypeScript is great with React too, because unlike many other frameworks... JSX <strong><em>isn't</em></strong> technically a "templating language"... it's simply a different syntax to call the function React.createElement() - therefore editor support is basically 100%, whereas there's a lot more effort to make typescript work nicely with "actual templating languages" used by Vue, Angular, Svelte etc.
Personally I wouldn't build anything in plain JS without TypeScript, aside from very very tiny amounts of JS you might throw into a wordpress site or something like that where you're not doing much custom programming at all.
I like the detailed post, it's clear you've put a lot of thought into this already. What I'd encourage you do is to take a step back try and look at things from the bigger picture first, before you get lost in the details. Consider the following questions:
- What is the measured impact this has on your app? What're the symptoms that you see? Have you run a profiler to concretely identify the problem, or is your current hypothesis just conjecture?
- Is your problem really a problem? Is 3000 documents a practical use case for your average user, or does the average user store 7 documents?
- Is this problem something that has to be solved? Something to consider: as long as the UI remains responsive and provides feedback to the user (i.e. a spinner or a progress bar), many people are willing to wait for a program to load.
That aside, some specific comments that might help you out as well:
> As I work with browser's storage and not server when querying, I am always working with all data in indexed db and can't use magic of pagination to get only needed data.
I disagree with this statement. This goes to my earlier point, but make sure you've measured and concretely identified the bottleneck - I also can't speak in specifics without seeing your app architecture, but I would be extremely surprised if the local DB query is what's slowing things down. You may not be able to paginate your fetch, but you can still paginate your UI, and I'd be more inclined to think the DOM rewrites for rendering your files is what's slowing things down, not the actual data query. 3000 documents doesn't sound at all like a large data set.
> (You really want class hierarchies to create user interface APIs.)
This is interesting to me; I know basically nothing about flutter code, but I do a lot of React, which has a pretty strict "no-inheritance" approach to UI building.
Computed property name.
Also the technique is specifically listed in the React Docs for handling multiple inputs: https://reactjs.org/docs/forms.html#handling-multiple-inputs
We had some issue with this happening in production in our app. It was even more painful for our users because the devices they use are heavily locked down with MDM software, to the point to where they can't use most hardware buttons. We found these white screens to be caused by unhandled errors that arise during a rendering cycle, and error boundaries were the fix for us. https://reactjs.org/docs/error-boundaries.html
​
I wrapped the entire app around a single error boundary that shows a friendly message to the user, records the occurrence in our error reporting dashboard, and forcefully remounts the root app component to simulate a restart. It's a rather crude solution, but it works, and it's a far cry better than forcing the user to call tech support to have their device reset. The nice thing about how error boundaries work is that we can put narrower error boundaries further down the component tree if we ever need something more granular.
>There's only one Twitter, YouTube, Facebook, etc.
That's absurd. Not only do all of these have competitors, there's also a ton of cross-competition. Twitter competes with Facebook, and they both have their own video hosting platforms. Then there's instagram and snapchat and vimeo who compete for screen time.
here's a table of video hosting services
here's 63 social media platforms currently active in 2018, some of them are quite niche, but the point is that it's not a monopoly there are ample competitors if you want to take your business elsewhere.
And more importantly, market share does not a monopoly make. I could write a twitter or facebook or youtube clone in a few hours and host it for under $20. Compared to traditional markets, that an unfathomably small barrier to entry. Facebook isn't buying up every domain name so I can't register one. They're not buying up all of Amazon's servers so I can't host my site. They're not pricing me out of bandwidth. In fact, facebook freely released the front end frame-work I would use to make their clone, which is one of the most popular frameworks on the web today. They have the market because they're the best product. If the market doesn't want it, they're free to leave for an alternative and they should. The problem is no one wants to walk away from the benefits of the more successful platforms, the larger audience.
These companies have built extremely successfully advertisement platforms, and people want to keep suckling at the teat so they decide it's a protected right to use it? That's some bullshit, and it sure ain't American conservatism.
Yes, it's called a fragment, basically sugar for a static array return. You need babel 7 i believe to do this, otherwise you can use <React.Fragment> ... this one would also allow you to pass a key.
Not related to the question directly.
YTSearch would be better to be called within componentDidMount.
Refer to this short post: Where to Fetch Data: componentWillMount vs componentDidMount.
I have experience with VueJS so I was familiar with most of the concepts and backend.
My starting point was ReactJS docs. After reading this I immediatelly started building. The other libraries I've learnt on the go from their home pages. As it's a pet project I didn't have to hurry. I've tried several different approaches to the same problem until I was happy with the result.
When it comes to PWA I didn't really need to learn too much. Create react app provides decent service worker for offline-first sites.
react-router + separate but reusable presentation components is the way to go. If you got hung up on prop drilling issues check out the React Context API, it's pretty great and solves that issue very cleanly and doesn't require any additional packages.
Uh... are we reading the same docs site?
https://reactjs.org/docs/context.html literally says, as the subheader:
> Context provides a way to pass data through the component tree without having to pass props down manually at every level.
There is a note further down that says:
> Context is primarily used when some data needs to be accessible by many components at different nesting levels. Apply it sparingly because it makes component reuse more difficult. > If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.
But that's more a question of "when should I use context?". The entire purpose of context, as a tool, is to pass some value down to nested components without passing it as props .
Don't see a release announcement on the React blog yet, but React v17.0.0 is now live on NPM.
Per the React 17 RC announcement, there are no new major features in React 17 - it's primarily about cleanup and transition.
Just my two cents on the article:
In a react app, I would refrain from using document.querySelector as it is a side effect. You want to use Refs instead. Or add a note for the reader that you did this on purpose to keep things focused on the actual tutorial.
I would also add the reason for adding { passive: true } to the event listener, since there is a big reason for this and that it would be a bad idea to blindly subscribe to the scroll event without adding it.
You should never use this.state inside the setState functions as you can’t rely on its value at that point.
Prefer the following: this.setState((state, props) => ({ counter: state.counter + 1 }));
https://reactjs.org/docs/state-and-lifecycle.html See the “State Updates May Be Asynchronous” section
If you use a PureComponent, it each should only change if their props change. So if the wrapping component gets new props that don't pass down to the child, only the wrapper will rerender.
https://reactjs.org/docs/react-api.html#reactpurecomponent
It only does a shallow comparison though, so if OP nests his props deeply in objects, they will have to use the shouldComponentUpdate lifecycle method, but it would avoid rerenders on props that are not included or OP deems inconsequential to the child. Though it's generally a good practice to only pass props that are relevant to the receiving component.
Use Asp.net only as backend API. Frontend nowadays is mostly Angular/React/Vue. https://docs.microsoft.com/pl-pl/aspnet/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
https://reactjs.org/docs/hello-world.html
You can start with simple json API and then consume it from react.
PureComponent only does a shallow comparison between props. You can switch over to a regular Component and make use of shouldComponentUpdate(prevProps, prevState) { ... } directly to maybe fine tune exactly what should cause a re render. You'd be surprised what would cause a re render for a component.
[Edit]
Also what are you using? Are you using Expo? I've noticed a big performance boost when I publish to expo which would make sense with all the webpack / babel stuff CRNA does when building your actual app.
Looking at https://reactjs.org/docs/optimizing-performance.html#virtualize-long-lists, they link to https://bvaughn.github.io/react-virtualized/#/components/MultiGrid. While this is not react-native, it could still maybe work?
Finally, after googling I found this: https://github.com/saleel/react-native-super-grid. React Native comes with FlatList and SectionList which extend the functionality of ScrollView, but are optimized specifically for performance when loading large lists. The link I just gave uses an implementation of FlatList / SectionList, but as a grid, which I think is what you're going for.
Let me know how it goes! I'd be interested to hear any performance benefits you get out of this. Heck, I may even try to build it.
To add to that, if you want to use the current state, provide a function that takes the current state:
this.setState((prevState, props) => ({ counter: prevState.counter + props.increment }));
Taken from here: https://reactjs.org/docs/state-and-lifecycle.html#using-state-correctly
No it's not deprecated. They recently added this method as a replacement for componentWillReceiveProps(). componentWillReceiveProps() will deprecate in v17.
From React documentation
>It is not recommended to use this lifecycle (componentWillReceiveProps) in the new code. If you need to calculate next state based on a change in props, use the static getDerivedStateFromProps lifecycle. If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead. For some use cases, you need to use both: getDerivedStateFromProps for a calculation, and componentDidUpdate for a side effect.
Deprecation notice on componentWillReceiveProps method.
>This lifecycle was previously named componentWillReceiveProps. That name will continue to work until version 17. Use the rename-unsafe-lifecycles codemod to automatically update your components.
> I didn't notice anything really changed on their main React website (https://reactjs.org/docs/hello-world.html) so I assume nothing is changed (so as long as I know about the conversion, I am good?)
I've been hearing for a while that the React team has been working on a massive overhaul of their docs but yea, nothing yet. I don't consult the docks much 😬 but often see complains that they can be outdated on certain subject matter.
babel-loader is a bridge to integrate Babel into Webpack(to process files by mask you provide through Babel before bundling with Webpack).
Next, with "plain" Babel you will need to specify a lot of different plugins to get transformation you need.
You will (almost - until you use Preact or don't want to have JSX transformation and prefer React.createElement instead) definitely need one or few plugins to process JSX for React. So you add @babel/preset-react instead of cherry picking separate babel plugins and configuring them manually.
Finally, you will definitely want to have transformation for language feature that not supported by all your target browsers. Do you need a plugin for spread operator ... or are target browsers all support it? Do you need polyfills for IE11? And what exactly? To solve this holistically we use @babel/preset-env and specify target browsers in config instead of connecting bazillion plugins manually.
Some great advice here. I'll echo the others and guess your problem is you need to learn the React "way" and way of thinking. Conveniently, they've anticipated just such a need!
One disadvantage, at least on first load, is that a lot of boilerplate React code will have to be reloaded for each domain.
It might make more sense to use code-splitting to load code only as necessary. This is React's recommended approach.
If you want to use your filter state outside the component where it was defined, you generally should define that state in a parent component. See: https://reactjs.org/docs/lifting-state-up.html
You’re starting to get close to the point where you’ll see why solutions like Redux were created.
If it doesn't need swish interactive behaviour without page loads then I just do it with templates. For everything else there is React.
React is surprisingly easy to learn, the API for core React is smaller than Django Querysets, it's all the libraries and infra around it that make it big and complex, with that in mind my main tips for learning React are:
1: use create react app to deal with all the infra stuff
2: under no circumstances should you ever "eject", if a web page tells you to "eject" to achieve something close that page
3: no libraries, use only React until you have learnt enough to know why you need the other things, you can do virtually everything without libraries, they just make it easier
4: no class based components, use hooks, they are the future
5: aside from underselling hooks the docs here are pretty good https://reactjs.org/docs/hello-world.html
I learnt React last year as part of my covid project: https://pypi.org/project/django-data-browser/
I would recommend learning React which requires JavaScript or TypeScript. The best way to learn is by doing tutorials like this.
This will teach you to build the front end, but knowing JavaScript or Typescript will give you a quick path to node.js which you can use for the back end. Python and node are the most popular languages right now.
> - Abusing the key property to make a component remount
This isn't an anti-pattern or abuse - this is actually the intended purpose, and a pattern that is recommended by the React team depending on what you're trying to do:
Yeah, I'd definitely say try/catch is your friend. Really your 'main' logic action should be wrapped in a try/catch no matter what, since this is the React subreddit, I think it's worth mentioning that this would commonly look like an error boundary at the top of your component tree.
If a hard error is hit, this error boundary component should catch it and do two things:
- Render a fallback like "Hey super sorry but something went wrong" to avoid everyone's favorite White Screen of Death (WSoD).
- Don't let that error die on the client. Tell yourself about it. Have a safe way of sending that error to your server so you can keep track of how often it's happening.
I usually include try/catch blocks through out my code if an error can happen outside of my control, and I want to control what happens within that component or part of the tree. For example, it's not like a failed network request for a resource should throw an error that bubbles all the way up to the error boundary, I'll just catch it, set some state in that catch that updates the render to let the user know what happened.
Whatever works for you, really.
ako koga zanimaju kodovi
ovo ti je trenutno najbolji (najkonkreniji) kurs za uvod u programiranje - pravljenje web stranica, jer danas je web sve
https://www.udemy.com/course/the-web-developer-bootcamp/
košta 12$ a ima ga i na torentu
kurs je beton, sadrži sve osnovno što treba za uvod u programiranje i pravljenje web stranica i jako je temeljit, i ne zahtijeva nikakvo predznanje
nakon savladavanja osnova web programiranja (HTML i CSS), preporučujem učenje React koji je iz godine u godinu sve traženiji
That's the approach you would use in direct-dom-modification scenarios like backbone.js apps or freestyle jquery proejcts. But with react, that's going to be a pain.
React much prefers unidirectional data flow - https://facebook.github.io/flux/docs/in-depth-overview/#structure-and-data-flow while not react-specific, it nicely outlines the idea.
React components should ideally be just instructions on how to render data. That data gets fed into the top of react render tree, react then figures out what needs to be done to get dom into the state needed by the data. If data needs changing, components trigger events, usually referred to as actions. Event listener catches that, modifies the data as needed, feeds the new data into the render tree, triggering a re-render of the whole react render tree. That sounds insane when you're used to jquery, but due to the tech behind react the performance is good. And on the upside, you don't need to think how to modify the dom after this or that happens, all you have to outline is the "initial render" part, because every render is essentially initial render.
That data and event handler might be redux, or plain react state or context, or one of many other solutions. Just remember this - it should be okay for your react components to re-render whenever they want. As long as the same data is passed to them, the output should be the same.
As for your immediate issue of modifying something many levels up, https://reactjs.org/docs/context.html context would be an easy solution.
I learnt by doing the tutorial on ReactJS.org (https://reactjs.org/tutorial/tutorial.html) I also got a small scholarship from Facebook thru Facebook developer Circles which gave me access to https://openclassrooms.com/ and did the react course on there (https://openclassrooms.com/en/courses/4286486-build-web-apps-with-reactjs) They give out a ton of mini scholarships and a few diploma scholarships every 6 months. I also learnt by doing projects for job applications and getting help at free meetups, there are lots in Berlin but most big cities have a lot.
From the React docs:
> You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance.
useMemoOne provides useMemoOne and useCallbackOne which are drop in replacements for useMemo and useCallback that provide a semantic guarantee (stable cache) if you need it
What do you mean by "silence"? It's explicitly called out in "breaking changes":
https://reactjs.org/blog/2018/10/01/create-react-app-v2.html#breaking-changes
https://github.com/facebook/create-react-app/releases/tag/v2.0.3
If you don't see a lot of people complaining about it, it might mean that most people weren't upset by this change. In either case you're welcome to file an issue to express your concerns. The behavior was changed in response to people's concerns about the previous one. Maybe we can find something better still?
Then the question was wrong. Autofocus is part of the HTML5 spec and is supported in every browser.
render(){
return <input type="text" autofocus />
}
And you can't do anything "as soon as the component renders" when all you can use is componentDidUpdate. The first render will always happen before componentDidUpdate fires.
https://reactjs.org/docs/react-component.html#componentdidupdate
> componentDidUpdate() is invoked immediately after updating occurs. This method is not called for the initial render.
The answer to question 3 is actually really simple. Since javascript allows you to call a function with less parameters than there are in the declaration you just check for undefined as the second parameter and then return another function.
function add(a, b) { return b !== undefined ? a + b : b => a + b }
For the answer to the first question read up about refs: https://reactjs.org/docs/refs-and-the-dom.html
Direct link to the section: https://reactjs.org/docs/hooks-intro.html#classes-confuse-both-people-and-machines
Quoting the relevant paragraph:
> In our observation, classes are the biggest barrier to learning React. You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers. Without unstable syntax proposals, the code is very verbose. People can understand props, state, and top-down data flow perfectly well but still struggle with classes. The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers.
>Is there a better way to separate the code than stuffing all the CRUD into one function?
Yes. You can essentially create your own "hook" by creating a function that uses a React hook, in this case "useState". You could even make it a generic thing that manages a collection of items. See the React docs here: https://reactjs.org/docs/hooks-overview.html#-building-your-own-hooks
setState is asynchronus https://reactjs.org/docs/react-component.html#setstate
this.setState({prop: value}, () => {
// access updated value here
})
These aren't necessarily mistakes that Reddit made, but as a general guide (for production)...
First and foremost:
- Webpack, or whatever bundler you're using, should be in production mode/use a production configuration.
NODE_ENVshould be set toproductionwhen building. I think Webpack 4 in production mode automatically takes care of this for you now, but I believe previous versions didn't (because lots of people missed this).
Other than that, React optimization is a bit of an art unto itself that comes with experience, but this article will give you some idea of the sorts of things involved if you can follow it: https://medium.com/airbnb-engineering/recent-web-performance-fixes-on-airbnb-listing-pages-6cd8d93df6f4
It's mostly:
- Don't unnecessarily pass props or set state that isn't needed for rendering.
- Selectively use
PureComponent(or implementshouldComponentUpdate) in places in the component tree that will benefit. - Avoid passing inline functions as much as possible (they can negate the optimization that
PureComponentprovides).
Then there are slightly more advanced performance techniques like:
- Memoization (also in that article).
- Server rendering.
- Code splitting.
- Windowing long lists.
- Data caching.
More info: https://reactjs.org/docs/optimizing-performance.html
No, it's being deprecated. Here's a post detailing alternatives: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html
The initial reaction of many is to use the new method getDerivedStateFromProps, but that is often not the correct course of action. Here's a post explaining that: https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html
- this.setState is a function (docs). It should be:
​
this.setState({ isWrong: true })
Use onClick event for button
<Button onClick={() => this.setState({ isWrong: true })} />
Tip: It would be more readable to call a function inside the component which calls
this.setState
Well, to make your life easier. You should only use componentDidMount. This is because react made componentWillMount legacy. And it will probably be removed in or around react 17. So its best to avoid it altogether. :)
In React, you shouldn't be doing multiple levels of component inheritance - you should only ever extend React.Component, which is an effectively empty base class. See the Composition vs Inheritance page in the docs.
> Vue doesn't require a toolset. You can drop the minified JS file in your <head> and call it a day. You don't need npm, a crapload of package, a build tool and an interpreter to make it work.
You don't need this for React.js either, as explained here. You can also just link the library for example using the CDN links without using NPM. So this kind of 'main point' is invalid.
Apparently React implements a heuristic <code>O(n)</code> algorithm. That doesn't mean worst cases wont approach O(N^3), but I assume it is possible to build an acceptably performant web application with React.
What UI library a product uses says nothing about anything important. Using Knockout tells me the product was started in ~2011-2013 and the company has a higher-than-average chance of using Microsoft tech elsewhere in their stack.
My best learning experience in my career was working for a team of brilliant developers working on a dead-end product with no market share, in a dead-end tech stack (C++/COM), with a long-since-dead fad of p2p.
If your goal is to pad your resume with buzzwords like React, don't go work there. If you have other, higher priority goals and this company can fill them, go for it.
There are a ton of things in modern libraries like React that are hard to appreciate without an understanding of last gen UI libraries like Knockout, such as React Async.
Lastly, Knockout is an awesome library made by a brilliant developer that got a lot right (computeds with implicit dependencies, solid two-way data binding, amazing dedication to backwards compatibility with older browsers, etc). It also gets some things wrong (shallow learning curve means people under use computeds, don't understand mvvm and just have fat views and no models, it doesn't mix as well with static typing like typescript/flow, confusing and hard-to-debug templating, etc). Knockout is definitely up to the task of building great UI (with smart developers behind the wheel).
Just use create-react-app. Everything is bundled and configured for you out of the box. https://reactjs.org/docs/add-react-to-a-new-app.htm
It sounds like it probably installed supporting modules and build tools.
Here's a line from the ReadMe for create-react-app:
> If you want to try React without hundreds of transitive build tool dependencies, consider using a single HTML file or an online sandbox instead.
The React docs are very good.
Not particular to react, but I also enjoyed Dan Ambramov's redux egghead course
- If its only one page, I can't really think of a reason to use Next. However, doing a project "In Next" would be doing a project in react, so if you want to demonstrate your knowledge of the two, Next makes sense.
- if you want the SSR aspect of Next, I would probably just use React DOM Server.
It's the most common way to create a React.js app. The React.js documentation even recommends this package.
> If you’re learning React or creating a new single-page app, use Create React App.