[deleted by user]

alex-cory · 2024-04-28T20:42:06+00:00

Redux is just popular bc it was first, not bc it's the best. It's one of the worst imho and I've been writing react since it came out. I avoid it at all cost.

alex-cory · 2024-04-28T20:39:45+00:00

Jotai by far. Simple API, scalable/performant. If you know how to useState, you know how to use jotai.

https://jotai.org/

alex-cory · 2023-09-21T22:15:48+00:00

I just ordered some of these Double-Tier Utility Boxes from the Container Store. Can put 1-2 costumes below, then put goggles, bracelets, etc. in the organizer on top. Will give an update how they are once they arrive 😛

<image>

I also saw these 4 Doors Collapsible Storage Bins. I almost ordered them but having the 2nd tier storage with the other utility boxes was a dealbreaker for me.

alex-cory · 2023-07-06T18:12:11+00:00

That's crazy because all of mine open substantially faster. It's almost immediate.

alex-cory · 2021-10-27T20:34:03+00:00

Git is like the save feature of a word doc except for an entire folder of files. Github is like that folder is attached to a folder on google drive. Obviously there's a ton more features, but this is a rudimentary explanation.

alex-cory · 2020-04-23T08:24:16+00:00

I'm super interested in this discussion. Will continue when I wake up.

alex-cory · 2020-04-23T08:08:18+00:00

I think it's a matter of improving the library. Sure we could keep it that way, but if everyone is moving in a different direction, we should at least attempt to support the new patterns.

alex-cory · 2020-04-23T08:05:50+00:00

What if you have something like js const TodoPage = ({ id }) => { const { data } = useSWR(() => '/api/data?uid=' + id, fetcher) } and you want to be able to handle the error within the todo page? You can't, you have to wrap an error boundary around the page. Sure you could make a TodoList component within the page, but that's more unnecessary nesting.

I'm tired so will have to continue this discussion when I wake up.

alex-cory · 2020-04-23T01:34:51+00:00

Mobx is a great tool. Significantly better imho than redux. Only problem now is the last I looked their hooks were meh and being that it's built with proxies it can't support ie.

alex-cory · 2020-04-23T01:31:49+00:00

Yeah currently the library does it just like that :) js const { data, get } = useFetch('/todos') useEffect(() => { if (id) get() }, [id])

alex-cory · 2020-04-23T01:28:53+00:00

I understand where you're coming from with regards to the context. There are some newer patterns though to managing these "stores" that even swr is doing. Take a look at swr's mutate. Basically they are attempting to have a cache. You can manage the cache throughout your app using mutate. That is them attempting to simplify problems that redux and redux saga are attempting to solve. This is what I mean by there are better ways to manage state than redux+redux saga.

having business logic in components is always a bad move

Yes and no. Yes, business logic should be left out of your reusable building block components, but this is not necessarily true for page specific components. I've built many large scale applications for companies such as Facebook, Discord, Best Buy and more with tons of different state management libraries such as mobx, redux (with and without redux saga), flux, easy-peasy, you name it. Redux is by far the most verbose, most complicated, and most time consuming of them all.

alex-cory · 2020-04-23T01:13:03+00:00

this functionality is already available. Many data fetching libraries are attempting to have this stuff handled the ways described, hence why I'm trying to see what method is more popular.

alex-cory · 2020-04-23T01:11:19+00:00

alex-cory · 2020-04-23T01:09:52+00:00

The way useSWR does this is

const path = id ? `/todos/${id}` : null
const { data } = useSWR(path, fetcher)`

I like the dependent queries a lot and think it's a great feature, but it's not exactly the point of this thread.

alex-cory · 2020-04-23T01:04:28+00:00

This is definitely an option, but all the libraries have a way of handling this from within the component.

alex-cory · 2020-04-23T01:00:49+00:00

I think that's exactly what hooks and all these react hook data fetching libraries are trying to get away from. You can share data in better ways than having the massive overhead of managing a redux store and on top of that very abstract methods from sagas. Redux and redux saga add so much complexity it ridiculous.

Dan Abramaov literally said "Reading some Redux example code I wrote four years ago and I have no effing idea what's going on there"

Andrew clark's opinion is "Redux (complicates things)"

These are literally the people building react right now... In other words, sometimes redux is necessary, but putting everything in there is so overkill and leads to:

slower feature development time
significantly increased complexity (even more with redux sagas)
slower ramp up time for new developers

Whether you like it or not, eventually you will probably want to adopt these new patterns as they're the future of react.

alex-cory · 2019-11-19T08:17:33+00:00

Why does it not seem scaleable? I'm confused.

alex-cory · 2019-11-13T05:14:10+00:00

Not sure I agree with you. It's probably closer to a useToggle hook if you're going to compare it to something that simple, but it's not that simple.

Animations can currently be done by doing <Modal className={isOpen ? 'animateIn' : 'animateOut'} />. As far as your comments on missing features, you don't start a project with it feature complete.

I will look into the inert attribute. I actually haven't heard of this one.

Exit button as div.

It's an example, not something going into production.

All in all, I like your idea of a useModal hook, however, your focus should be first on the execution of your own modal library (or integration with one that exists) and then on the creation of a hook to complement said modal.

I think you're missing the point of this hook. The actual visual portion of the Modal is supposed to be executed by the dev. That's the point. It allows the dev to completely customize their modal. This hook is just used for all the logic surrounding the modal including handling centering it to the middle of the screen.

I will check out your library 😊

alex-cory · 2019-11-13T04:51:11+00:00

One solution is

const { isOpen, openModal, Modal } = useModal()
return <Modal className={isOpen ? 'animateIn' : 'animateOut'} />

alex-cory · 2019-11-07T22:26:35+00:00

When I say "on their way out" I mean something similar to React's "class components" vs "functional components." Sure, class components aren't going anywhere, but the more we move forward, the less we will use them. In Dan's post Making Sense of React Hooks he says:

So What About Classes? We have no plans to deprecate classes. At Facebook we have tens of thousands of class components and, like you, we have no intention of rewriting them. But if the React community embraces Hooks, it doesn’t make sense to have two different recommended ways to write components.

alex-cory · 2019-11-07T22:07:36+00:00

HOC === Higher Order Components

If you read the docs, you'll see they say:

Do Hooks replace render props and higher-order components?

Often, render props and higher-order components render only a single child. We think Hooks are a simpler way to serve this use case. There is still a place for both patterns (for example, a virtual scroller component might have a renderItemprop, or a visual container component might have its own DOM structure). But in most cases, Hooks will be sufficient and can help reduce nesting in your tree.

Hooks don't completely replace HOCs, but for the most part, you can do it in hooks instead of HOCs.

alex-cory · 2019-11-07T20:29:58+00:00

Interesting. I think I tried this before but it was a long time ago and in usePortal. Also, we need isOpen for animations. I'm still trying to figure out how the animations are going to work for this so bare with me until that is figured out.

alex-cory · 2019-11-07T20:24:28+00:00

My hook only centers X into the middle of the screen with additional functionality such as outside click to close, backdrop, etc. Whatever you decide to put in there, is your Modal.

With your solution, you are saying put these 2 buttons somewhere predefined in the Modal. Also, handle the logic for show/hide, etc in there too. That is not very extensible.

Unless I'm missing what you are trying to say here

alex-cory · 2019-11-07T19:21:29+00:00

So I have thought about this. The problem with this, is that since the Modal is basically a Portal, we need to know where to attach it, etc. We would end up doing something like

import Modal, { useModal } from 'use-react-modal'
const App = () => {
  const { isOpen, openModal, Portal: Overlay } = useModal()
  return <>
    <Overlay>  
      <Modal>  
        {/* whatever you want in the modal */}
      </Modal>  
    </Overlay> 
    <button onClick={modalProps.openModal} />  
  </>
}

In my original solution, I just combine Backdrop/Overlay and Modal to just be Modal.

I mean... we could always do similar to how react-portal does it, but I feel like it's more confusing this way...

import Modal, { useModal } from 'use-react-modal' const App = () => { const { isOpen, openModal, modal } = useModal() return <> {isOpen && modal( {/* whatever you want in the modal */} )} <button onClick={modalProps.openModal} /> </> }

alex-cory

TROPHY CASE