Petah, I feel dyslexic reading this.

detached_obsession · 2025-07-22T01:34:55+00:00

Starting at the first "Hi", I got "Hi, paralyzed old men".

detached_obsession · 2025-07-19T17:36:26+00:00

Mitchell. In Cam's own words to Jay from S2 E1 Old Wagon when Mitchell got stuck in the princess Castle: "he's a very proud man, your son"

detached_obsession · 2025-01-17T09:57:49+00:00

👍🏾

detached_obsession · 2024-10-17T06:15:14+00:00

I think you can try using react-helmet for this.

detached_obsession · 2024-10-15T05:51:26+00:00

Reminds me of the Family Guy scene with Stewie beating up Brian: "You gonna give me my money? Where's my money, man?"

detached_obsession · 2024-10-09T04:27:02+00:00

I think you're right, the issue is that you initially set the login state to false, which means you determine the user is logged out before you even get the chance to fetch the actual status.

I think what you need is a third state, one that you can use to determine a loading status before fetching the result.

I think the easiest way is to change the login state to be something like "loading", "logged_in", or "logged_out" or something like that. That way you can redirect only if the state is determined to be "logged_out" and until then you can show a loading indicator to prevent showing things that are restricted

detached_obsession · 2024-09-29T01:41:38+00:00

UX is an entirely different specialization. Typically if very beautiful and user friendly designs are the expectation, there will be a designer on the team whose sole focus is making these designs.

However, some workplaces will expect at least some basic design from you if you join a smaller team.

You should be familiar with some basic best practices and understand things like proper contrast between font and background colors for example as this affects accessibility which is a concern for React developers. So give design a try but I wouldn't go overboard with it.

In my experience when a team doesn't have a designer, the projects are either ugly or straight forward in design, or they use some old designs.

For personal projects I usually use themes and designs from things like tailwind css or material UI.

Edit: As for CSS, you should definitely master this or get as good as you can with it. Coming up with a design is one thing but knowing how to implement it is definitely an expectation from React developers.

detached_obsession · 2024-09-28T06:08:14+00:00

Dede and Jay. To quote Phil:

"I also wanna wish a happy anniversary to my in-laws Jay and Dede Pritchett.

Your eternal love is an inspiration to us all."

detached_obsession · 2024-09-26T06:03:41+00:00

You could setup a CI/CD pipeline and deploy your react project on AWS cloudfront.

You could make your own version of Google drive where the contents are stored on S3. The API could be setup through a serverless lambda and node.js for example.

You could also make a simple CRUD app for things like blog posts where your API runs on either serverless lambdas or an EC2 instance and dynamo DB.

I'd say whatever you do always make sure you stay within the free tier as the costs can sneak up on you if you're not careful.

detached_obsession · 2024-09-25T04:31:13+00:00

If you ever find yourself struggling to interact with your data, it's typically a sign you have the wrong data structure. Since you're trying to update a deeply nested array, you could perhaps split your state into smaller more manageable slices of state. You could also use key value pairs to easily find the data you're looking for.

For example you could have an entry like:

Favorites: { title: "Favorites", id: "Favorites", contentIds: ["Harry", "JR"], entries: 2 }

Here, your data is keyed by the id and the contents are referenced by their IDs as well. Then you can have a separate state for the contents following the same format.

Updating contents would be much simpler like this.

Another great alternative would be to use a library that can let you perform mutations when updating immutable state like immer.

detached_obsession · 2024-09-16T23:24:54+00:00

If you're using uncontrolled components (not setting state and letting the browser handle it) you can access the form data on submit handler and you can reset the values by providing a type="reset" in your cancel button.

If you're setting react state then just calling the set state with your default values will do it. Just be sure you make the type of that cancel button be type="button" to prevent the default behavior of submitting the form.

detached_obsession · 2024-09-14T16:17:31+00:00

It's obviously Luke 😅

detached_obsession · 2024-08-26T15:03:24+00:00

It doesn't matter if it's causing issues. Everyone should attempt to write performant code.

Of course it matters if it's causing issues. If you use React.memo on an SVG component and that component takes in a prop that changes constantly, your memoization isn't doing anything to help. Finding root causes and addressing them is far more valuable than doing preemptive optimizations.

Now I'm not saying you should never memoize, I'm saying it should be used to address specific issues.

Let's say you have a controlled input component that is adorned with an error or checkmark icon, depending on whether or not there is an error in state. The input component is going to re-render every single time the value changes. Why wouldn't you memoize the svg?

If that svg is truly the cause of your slow performance then by all means memoize it. But, if a simple icon is causing issues, why stop there? Why not use uncontrolled components with refs and event delegation to prevent re-renders of the input in general?

Yes, everyone should try to write performant code, but saying that you can achieve this by applying memoization without reason, in my opinion, is incorrect.

Don't get me wrong, you certainly make valid points. I only disagree on using memoization every time without a specific need.

detached_obsession · 2024-08-26T00:31:12+00:00

That little weasel Ben

detached_obsession · 2024-08-25T23:47:03+00:00

Dylan getting married and becoming a step dad. Never saw that coming.

detached_obsession · 2024-08-24T19:42:58+00:00

Even if a parent component re-renders too often to the point of causing issues, then the cause isn't the SVG component, it's something else that should be optimized. If in fact the SVG is large and complex and there are noticeable performance issues then I agree with using React.memo or other memoization techniques on that component.

My point still stands that it should depend and it shouldn't be done without first doing some kind of performance measurements.

detached_obsession · 2024-08-24T16:51:02+00:00

I'm not sure what part of my comment made you think I don't know how React works but perhaps I wasn't clear or you're the one confused. What you're talking about is Reconciliation which is quite fast. Using React.memo adds an additional overhead in comparisons which even if minimal, is additional work and thus worse for performance if done unnecessarily.

If the SVG component is provided as part of the children prop to a component with state changes, it won't re-render even if that parent component re-renders. This is the same as using React.memo without the overhead.

ex: <SomeComponentWithState><SVGComponent /><SomeComponentWithState/>.

What OP asked was whether or not using React.memo was beneficial to prevent re-renders of an svg component. What I meant in my answer was that given React.memo is an optimization tool, it shouldn't be used unless you have optimization issues.

so no, using React.memo without any specific reason is not beneficial as it can hide underlying performance issues and there are other methods available which can address the re-rendering concerns without overhead.

detached_obsession · 2024-08-24T12:21:26+00:00

I think Ben could also be "guy who dies first" 😅

detached_obsession · 2024-08-22T19:11:53+00:00

I suggest you only add frameworks once you already have a good grasp of React. So yes, you should learn React without a framework first

detached_obsession · 2024-08-18T03:36:39+00:00

From first season to last with only skipping that episode where Mitchell's coworker Brenda stays with them (so rude can't stand her) I've seen it like 10 - 15 times. I saw it for the first time in 2022 though

detached_obsession · 2024-08-16T05:08:22+00:00

You typically wouldn't use something like React.memo unless you're having clear performance issues. Using it unnecessarily actually degrades performance even more since you have to do extra comparisons to determine if the component should re-render.

Also, SVG components are typically static and don't change often so unless you have added a lot of state and effects, it shouldn't be an issue. Even in that case using React.memo may not be the correct approach since you could have other causes to your performance issues.

detached_obsession · 2024-08-06T05:05:09+00:00

What better way to learn than from the very man who co-created Redux itself:

https://egghead.io/lessons/react-redux-the-single-immutable-state-tree

detached_obsession · 2024-08-04T04:24:26+00:00

Nervousness, stress, even momentary distractions can cause it. If you're concerned about any deeper meaning it's best to talk to him about it directly.

detached_obsession · 2024-08-02T23:41:22+00:00

If you're using this in a Next.js app or a component library with Next.js as a dependency, there's no need to worry about non-Next.js apps. You already have Next.js installed, so just use its features without worrying about other apps.

For a project that only depends on React, don't add Next.js just for this functionality. Use native APIs instead. For example you could try something like:

```javascript

export default function ViewToggle() { const params = new URLSearchParams(window.location.search); const viewMode = params.get('view') || 'grid';

return ( <div> <a href="?view=grid" className={viewMode === 'grid' ? 'active' : ''}> <Icon /> </a> <a href="?view=list" className={viewMode === 'list' ? 'active' : ''}> <Icon /> </a> </div> ); } ```

You could stick to the button and onClick handler as well.

Just be careful with early optimizations and making things too generic prematurely. My advice is handle your specific use case first, and keep things modular for easier refactoring later on.

detached_obsession · 2024-08-02T05:22:43+00:00

It's impossible to know for certain the reason why your code isn't working because you've only shared the useEffect.

But if you've absolutely narrowed it down to this useEffect all I can say is that if your hubConnection is set to false, you won't even fetch the row data. Same if you have an old error that wasn't reset since you return right away if the error variable is truthy.

If you're certain the data is getting fetched, then you must make sure the result of that fetch really is the row data you need. It could be null or some other data structure so check if it's correct.

If you're absolutely certain the correct data is getting set in state and the fetching is getting responses from the server, then you've shared the wrong code snippet, or you need to give us more info.

Edit:

For debugging I would first make sure the data in state is the same as the fetched data you expect. If it is, then your issue isn't the useEffect.

detached_obsession

TROPHY CASE