I'm quite new to web dev just 6 days of learning. I heard react combines both html and js in the same file and i hearn tailwind combines html and css in the same file .does that mean if i use both i can develop everything in only one file format?

No it doesn't all Tailwind css does is generate classes that you use in your jsx (react.js version of html) it doesn't got any html its just css all you really do is use a ton of classes. But if you new at this it's best to start working with just css and html before going to react.js and tailwind not knowing the basics will hurt you badly in your career and projects it will make you look solutions for things that do not need it, it will take you much longer to do basic simple looking layouts and so on.

I am currently learning css but it's so tedious can't do things right i see a YouTube video saying tailwind is so easy to things right. i will try to learn plain css concepts force myself

The thing is with tailwind css you need to have a solid understanding of css fundamental. The vanilla css. I use tailwind css in my project, has been a breeze but you really, and I repeat you really really need to understand the vanilla css. Otherwise you will make a spaghetti without knowing what utilities class to use from tailwind css

Go for it. React is JavaScript and Tailwind is css classes. It doesn’t matter if you start with vanilla or not. Start building stuff, and give yourself challenges to make this or that functionality. You’ll have to do a lot of research to figure out how to do stuff either way and your knowledge and understanding will grow. I disagree with the whole notion that you have to build stuff old school first. Don’t overthink it, just start building.

 

More or less, yes.

But if you are new to web dev, you are probably getting way ahead of yourself by jumping into React. You should have a solid understanding of building web apps without React first. You'll be doing yourself a big disservice starting here.

 

I don’t know how libraries and frameworks like React and Tailwind would make a lot of sense without some fundamental knowledge of JavaScript and CSS. These aren’t shortcuts.
Seriously, learn JavaScript before trying to learn React. React IS JavaScript. It is a JavaScript library…. Written in JavaScript.

I’m with you on styling. Not my favorite thing. If you want to cheese out on something like bootstrap I guess I wouldn’t blame you.. but you can’t skip or skim JavaScript. It is mandatory.

 

You comment multiple times that you're finding it tedious. After just 6 days? If you dislike learning the absolute basic fundamentals then honestly it may not be for you. The first few weeks are supposed to be fun. If you hate it already it doesn't bode well. Looking for shortcuts and easier ways won't work- the fundamentals never change. Tailwind is just CSS in different syntax. React is still JavaScript and HTML fundamentals and if you don't know them, React won't help you.

 

 

Is it bad to have components that return null and are used just to subscribe to some events or for other purposes that do not include UI.I know that if there is just logic to be handled then use hooks but

1. Hooks work only with FC and

2. Hooks have to be called on the top of the component so they might not just be available on the top?

I have created one simple example here where I created a component just to "subscribe to some events" where it subscribes to events only if there is a user available and I am storing the user in redux I know this is not a real case because if I wrapped the <App/> with the provider in index.js rather than wrapping the content in App.js I could use the hook on the top but to be clear what I mean I did it that way because not always you can use that wrapper in the outermost component.
Is the GlobalSubscriber breaking any rules?

 

I don't think that you're breaking any rules per se, but if you're using a component just to add some logic to another component you should either use hooks instead (if using FCs) or use a HOC (higher-order component) that wraps around the component that needs the logic, rather than having to render the component by itself with no UI to return.

Perhaps the main reason hooks were created in the first place was to avoid having to use components to reuse logic. That said, if you need to use class components, read more about HOC since that is the way: https://reactjs.org/docs/higher-order-components.html

This is a great answer. Higher order components are basically identical to hooks in functionality and how confusing I found them was one of the reasons I was so happy to immediately move over to hooks/FC almost immediately after learning old react.

Yes thank you!! Hooks reuse logic, components are ui that may or may not have some logic. If there is some reusable piece of logic with no UI, it goes into a hook 100% of the time

 

JSX component can be added conditionally. Hooks cannot, by design.

If to choose between JSX with plain condition operators like && or custom hook with additional shouldIBeRun boolean flag or even callback which returns true/false, I'm all for JSX and component which returns null

PS composition (JSX or HOC) is way more flexible than adding hook into a host component. Meanwhile for HOC we cannot wrap conditionally based on some component state(would require to lift state to parent so passing as props which not always optimal). JSX is most flexible here.

[upd] react router's <Navigate>(former <Redirect>) works exactly this way

Most of the answers here are right, that you want to avoid this pattern if possible, and use custom hooks, BUT, no one is really answering your question about the specific use case where:

You have a component, usually your root component, that needs to consume something that depends on a provider declared in that component. This happens commonly with redux, if you want to track user state (or something like that) at root and render something differently depending on that state.

To solve that problem with a hook instead of an empty component, you simply need to wrap everything inside the provider in it's own component, then access the data dependent on the provider in the sub-component. I altered your codesandbox with how I solve this problem.

 

It's bad practice.

While it's true that hooks only work with functional components, but that's what you should be using unless you're updating some older code base. Even if you have a good reason to use class components, they are methods for pretty much everything that hooks are used for.

Hooks have to be called on top of the component and that shouldn't be an issue with anything you may want to use them for. I'm not quite sure what you mean by hooks not being available on the top.

What I mean is that if I wanted to use it in the top in the App.jsx the useSelector() hook it wouldn't be available because the the Provider is wrapping the content inside the app, but if I created a component that returns nothing but just to use the useSelector hook and place it inside the App.jsx the hook would be available, I know that if I move the provider to index.js then it will be available in the App.jsx but what if you are using another wrapper that you can't just wrap the whole app

 

Recently bought a udemy course and it said we have more functionality when using class based components and when i googled it, it said class based components are no longer useful and it will slowly vanish from react ?

Technically class based components are more "powerful" but as far as I'm concerned only so much as they can handle error boundaries which really means that you need one error boundary component made as a class that wraps whatever it needs to wrap. Everything else should be functional these days. I work on lots of class based components as have an app that predates functional, so I wouldn't rebuild everything in functional, but wouldn't write new class components.

Edit: to clarify, powerful isn't actually better. You should aim to always use the least powerful tool that does the job you need it to do. Functional components with hooks makes simper code, not more powerful code.

 

It is good to understand how class components work but focus on functional components. One of the apps I work on at work use some class components and I can work with them fine but everything else we do is functional components with hooks. Also learn typescript.

You should learn them so you know how to work with them but you shouldn’t use them. I rebuild every class component I find but occasionally you’ll run into one you shouldn’t upgrade and you need to know what you’re working with in those cases.

Functional components have been the industry standard for a few years now. It’s okay to learn class components, but functional components + hooks is the way to write react today.

You have theoretically more functionalities in that you can specify functions for each lifecycle method of the component. Other than that I think theres not much going for class components anymore. But even then, in practice you can do all you need with function components amd useEffect hook

I would go over the material, it would help you understand functional components (at least the idea of lifecycle in react). Focus on functional components after that. Also it might come in handy if you will need to maintain a legacy codebase. Good luck

Honestly, knowing lifecycle is the worst thing you can do. Hooks work differently from lifecycle in subtle ways and have a very different mental model - learning about lifecycle makes it a lot harder to actually understand hooks.

 

ith so many different screen sizes out there I'd like to make my applications as responsive as I can. I've been using React Native for the most part, and I have the iPhone 13 Pro simulator open for testing purposes. But let's say I want someone with an iPhone XR, or Pixel 6 to use my apps. What should be done when styling components to make sure they will adapt automatically to new screen sizes, since it would be unreasonable to style each component for each screen?

Should I be using percentages, flexboxes, or something else? This is one area I struggle with when working on the frontend.

 

You're right about it being unreasonable to style each component for each screen size, so that leaves us with flexboxes and percentages.
Try not to actually define the width of anything(unless it's so small that'll never be greater than your screen) and just let the content fill in the empty space.

You can should always simulate on different screen sizes too just to make sure everything is correct, but generally I like to start on the smallest screen size. If the content fits on a small screen it'll fit on a larger screen.

So React is all about creating reusable bits of presentation logic (components) and using them to compose views. Now that we have hooks, we can actually simplify this composition further: hooks allow us to encapsulate certain behaviors, often composed of multiple hooks, into functions that integrate directly into React’s renderer (using the new React Fiber, which we won’t dive into here) to automatically update the components using them.

useState

useState allows us to have stateful functional components! you call useState(initialValue) and it returns a pair of [state, setState]. Because it returns an array and not an object, you are free to name these references however you please. Most importantly, useState hooks into React DOM and triggers a render when you use the setState function returned from it, so it works just like this.setState would for class components.

useEffect

useEffect will normally run its code every time a component re-renders, however it accepts a second argument, an array of variables, that inform useEffect that it should only re-run when a value inside the array is changed. When provided an empty array, it will never re-run, so it behaves exactly like componentDidMount! The return value for useEffect should be a cleanup function, if required, so that it can be run before the effect is re-run, or the component is being removed from the DOM. Here we specify an anonymous function that will remove the event listener when this component is un-mounting (sound familiar? this is what we’ve been doing inside of componentWillUnmount).

Now this seems pretty good, but what happens if there are multiple places where things on the page need to render based on a breakpoint? We shouldn’t be setting up new event listeners for the same event every time one of these components is mounting, especially since we only have one window resize to listen for.

useContext

One of the ways hooks have really made things better is when using the Context API. Previously, using Context required using Consumer and Provider components, and utilizing the Consumer in any component that needed access to the value. This led to devs creating Higher Order Components for providing context as props (for example, react-redux's connect) or simply very verbose code. Now, with useContext, we no longer have to use Context.Consumer Components to make children aware of values from Context.

Let’s rewrite the above component, using Context and an App-wide WindowDimensionsProvider.

 

 

export default WindowDimensionsProviderexport const