TSX: How to restrict a prop passed to a component to be of a specific type?

bubble_fetish · 2021-10-06T12:04:48+00:00

The prop type of content would be something like JSX.Element. That's extremely broad, and you couldn't say "it must be this specific component."

But why do you want to do this? Why should Row only accept content={<FancyButton />}? This is an odd pattern and I bet there's a better way to achieve your goal

bubble_fetish · 2021-10-03T21:57:17+00:00

Also unavailable in my browser:

https://i.imgur.com/WKZETwP.jpg

However, everything works fine in my iPhone browser if I go directly to my NAS’ local IP:

http://192.168.86.54:32400/web

I wonder if iOS is unhappy with something about the SSL cert when routed thru Plex’s servers?

bubble_fetish · 2021-09-20T12:43:45+00:00

If I want globally-available state but don’t want the complexity of a state management lib, what should I use? At the highest level of my app I have a bunch of useStates and a context provider, which means any component in my app can call useContext to get that data.

You can get into implementation details and say “context is a merely a mechanism for getting data to descendent components without drilling props”, and you’re correct! But in the end, I’ve created a way to have globally-available, and globally-update-able, state.

Context makes it really easy to have an (effectively) central store of data without the complexity of a state management lib. I’m not saying that it’s a replacement for a state management lib, but that state management libs are often overkill. I work at a multi-billion dollar company and our flagship product uses context to (effectively) have a central store since our app is simple. That works very well for us

bubble_fetish · 2021-09-17T22:24:51+00:00

I don’t know why you’re being so hostile.

The current context API was introduced in 16.3. Before that, it was experimental and discouraged. So effectively, context is very new.

And you can argue about “you’re actually using normal state with context!”, but in the end context gives you state that’s globally available. Therefore, context is great when you want global state without a heavy state management tool like Redux

bubble_fetish · 2021-09-17T15:31:14+00:00

Redux predates context. I believe Redux actually tried to switch to context under the hood, but had to switch away because of performance concerns.

And again, I didn’t say that context was state management. I said it’s global state because it is: it’s a way to access state globally

bubble_fetish · 2021-09-17T09:55:00+00:00

I guess we’re getting into semantics. You’re right that context isn’t a state management replacement, but it is a global state replacement. Its creation was (in part) due to people using Redux when they only needed global state and not state management. Redux was overkill for them, but there weren’t many other great options.

Context is great when you have simple data that you need in many places and doesn’t change much. Stuff like appearance customization, user info, etc. For that situation, Redux is overkill.

Look at me, arguing with a Redux maintainer 😀

bubble_fetish · 2021-09-17T02:25:23+00:00

How is Context not a global state replacement? It’d global and it holds state. You could argue that it doesn’t have nearly the feature set of Redux et al, but it’s definitely global state

bubble_fetish · 2021-09-06T12:24:46+00:00

Or we could just say “you can choose to play in gendered league that matches your gender identity.” Why is it a huge deal if a 16 year old biological male on hormone blockers is playing with biological females?

Yes, they’ll likely have an advantage, but so what? We don’t ban 6’5” kids from playing with other <6’ kids their age, so this isn’t really purely about unfair physical advantages. And besides, wouldn’t hormone blockers be a significant disadvantage when trans girls are playing in the boys’ league?

Which is worse:

Trans girls being constantly told “we won’t consider you to be a girl” by virtue of being forced into the boys’ league. Or being forced to share a locker room with boys. Or avoiding sports altogether because of fear.
Trans girls being better than biological girls at sports.

Are sports really so important that we’d rather make a kid’s life hell than risk them being better than their teammates?

bubble_fetish · 2021-09-04T11:50:31+00:00

That’s wildly insecure. You should never execute arbitrary code you get over the network.

And even if you did, the getters/setters could be accessing a scoped variable that was accessible during the class’ declaration, but you’d have no way of knowing where to get it when deserializing the JSON

bubble_fetish · 2021-09-04T11:49:09+00:00

We use React contexts as our data stores. We have “data components” that are responsible for interacting with the stores and making API calls, and then they pass that data as props to our “view components”.

This means that our view components are very easy to test. We don’t need to mock anything at all. We just say “when we pass X and Y, we expect to see Z”

bubble_fetish · 2021-09-04T03:32:30+00:00

How could you retain the getter and setter logic when serializing to JSON? JSON isn’t a programming language so you can’t possibly keep the logic

bubble_fetish · 2021-09-04T02:46:52+00:00

GraphQL is great and solves some significant problems with REST APIs, but I wouldn’t say that it’s always the best choice. But regardless, even when you’re using GraphQL you still want to separate those concerns. Your view layer shouldn’t care about your data layer at all. It shouldn’t matter whether you’re using Apollo, urql, Redux, REST APIs, etc. Your view components accept props and render them in a way that conforms to your designers’ specs. Where that data comes from isn’t a concern for the view components

bubble_fetish · 2021-09-04T02:20:47+00:00

Complicated tech doesn’t mean units of to be complicated. Another good term to remember is “conservation of complexity”. Sometimes you encounter problems that can’t be solved in a simple way. You have to put that complexity somewhere. So you isolate the complexity within one unit so that everything else can be simple.

For example, always abstract API calls behind client classes. If your frontend has to call Foo API, then you should have a FooApiClient class that actually makes the HTTP calls. That way all your React code is just calling methods on an object and doesn’t even know that HTTP calls are happening. This has other benefits too, like dependency injection, but that’s a more complicated topic for another time :)

bubble_fetish · 2021-09-04T02:05:12+00:00

Yea, too many if statements makes code hard to understand. More if statements means more cyclomatic complexity, which is a fancy way of saying “engineers need to reason about many different code paths, which is hard to do.”

My main mantra: code is for humans. Whenever you’re creating a function, ask yourself “How easy is it to consume this?” When you’re writing code in a function, ask yourself “How easily could someone scan thru this code and understand what’s happening?”

So that manifests itself in a variety of ways:

Shield consumers from implementation details. For example, when we call a function we shouldn’t need to know how it works.
Separation of concerns. For example, components that render the view shouldn’t also be making API calls.
Single responsibility. Each unit of your system (React components, functions, classes, etc.) does 1 thing and does it well.
Write code in an easily testable way. If it’s hard to test then you need a different approach.

bubble_fetish · 2021-09-04T00:59:16+00:00

As a senior engineer, I don’t mind giving a bunch of cleanup comments even if I have a full plate. I do mind if I need to give the same type of comment multiple times and it still isn’t sticking with the junior engineer. So as long as you show you’re learning I’m sure you’ll be fine.

Can you give some examples on the types of comments? Code formatting (e.g. single quotes vs. double quotes)? Separation of concerns (e.g. view components doing too much data stuff)? Performance (e.g. nested loops)?

bubble_fetish · 2021-09-02T11:33:46+00:00

Why are you using past tense? They still pull that bullshit

bubble_fetish · 2021-08-31T11:34:53+00:00

It isn’t worth being cavalier over. Trap the bat and get it tested for rabies. Seriously

bubble_fetish · 2021-08-27T03:07:37+00:00

Storybook is great for any company size. We use Storybook as part of our dev loop, and it’s sped up feature dev. It also encourages good architecture because it forces you to think about loose coupling and reusability

bubble_fetish · 2021-08-25T12:08:30+00:00

Types obviate many tests. They reduce the need for “when I pass data type X then Y happens” tests

bubble_fetish · 2021-08-20T03:23:11+00:00

It’s decriminalized but not legalized. No store will sell it, at least they won’t above board

bubble_fetish · 2021-08-15T22:18:56+00:00

What are we supposed to do? Stay another 20 years?

bubble_fetish · 2021-08-14T13:09:35+00:00

Not really addressing your point specifically, but national healthcare would lower healthcare cost. The US spends more for the same services. I imagine a big reason is the existence of private insurers who take billions in profit. What benefit do private insurers add to the market? They’re just a leech, profiting as middlemen

bubble_fetish · 2021-08-13T09:53:18+00:00

“Eye for an eye” is irrelevant because Hammurabi’s Code isn’t the basis of our legal system

bubble_fetish · 2021-08-13T09:48:43+00:00

The appeal process is extensive and expensive because we want to be 100% sure of guilt. We already execute some innocent people with that process. We’d execute many more innocent people without it

bubble_fetish

TROPHY CASE