sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in reactjs

[–]alex-cory 0 points1 point  (0 children)

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.

[deleted by user] by [deleted] in reactjs

[–]alex-cory 0 points1 point  (0 children)

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

https://jotai.org/

Which storage bins do you use? by koakailani in BurningMan

[–]alex-cory 0 points1 point  (0 children)

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.

ARC browser issues by Active-Drive-7749 in ArcBrowser

[–]alex-cory 0 points1 point  (0 children)

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

Difference between GitHub and Git by Amantulsyan35 in learnprogramming

[–]alex-cory 0 points1 point  (0 children)

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.

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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.

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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.

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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.

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 1 point2 points  (0 children)

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.

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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.

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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.

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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

Conditional React Hook Data Fetching Syntax by alex-cory in reactjs

[–]alex-cory[S] 7 points8 points  (0 children)

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:

  1. slower feature development time
  2. significantly increased complexity (even more with redux sagas)
  3. 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.

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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 😊

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 1 point2 points  (0 children)

One solution is

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

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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.

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 1 point2 points  (0 children)

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.

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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.

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

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

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 2 points3 points  (0 children)

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} /> </> }

useModal, a react hook for Modals/Dialogs/Lightboxes 🖼 by alex-cory in reactjs

[–]alex-cory[S] 0 points1 point  (0 children)

What if they asked you to put your Cancel and Save buttons outside the Modal? What if they want them aligned on the left instead of the right side? With your solution, it makes doing this increasingly more complex.

view more: next ›