Live data from Hacker News

jQuery 4

blog.jquery.com

291–300 of 313 posts

Re: jQuery 4

#291

Earlier quoted context omitted.

My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in. Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above. Compare this to Vue's Pinia library where you can simpl…

You can use Tanstack Query or Zustand for this in React. They essentially have a global state, and you can attach reactive "views" to it. They also provide ways to delay rendering until you have the data ready. Your example would look like: const id = useState(...); const numericState = useState(0); const q = useQuery({ queryFn: async (context) => { const data = await fetch(..., {signal: context.signal}); const deriv…

I've used React Query and Zustand extensively in my projects, and unfortunately Zustand suffers from the same issue in cases where you aren't dealing with async data. I'm talking about React state + data that's already available, but can't be used to initialize your store before the first render cycle.

Here's how Zustand gets around this, and lo-and-behold: it requires React Context :( [1] (Look at how much boilerplate is required!)

React Query at least gives you an `initialData` option [2] to populate the cache before anything is done, and it works similarly to `useState`'s initializer. The key nuance with `const [state, setState] = useState(myInitialValue)` is the initial value is set on `state` before anything renders, so you don't need to wait while the component flashes `null` or a loading state. Whatever you need it to be is there immediately, helping UIs feel faster. It's a minor detail, but it makes a big difference when you're working with more complex dependencies.

1. https://zustand.docs.pmnd.rs/guides/initialize-state-with-pr...

2. https://tanstack.com/query/v5/docs/framework/react/guides/in...

---

I guess I could abuse React Query like this...

  function useGlobalStore() {
    const myHookState = useMyHook(); // not async

    return useQuery({
      initialData: {
        optionA: true,
        optionB: myHookState,
      }
    });
  }
And you'd have to use `queryClient` to mutate the state locally since we aren't dealing with server data here.

But here's what I really want from the React team...

  // Hook uses global instance instead of creating a new one each time it's used. No React Context boilerplate or ceremony. No wrapping components with more messy JSX. I can set state using React's primitives instead of messing with a 3rd party store:

  const useGlobalStore = createGlobalStore(() => {
    const dataFromAnotherHook = useAnotherHook();

    const [settings, setSettings] = useState({
      optionA: true,
      optionB: dataFromAnotherHook,
    });

    return {
      settings,
      setSettings,
    }
  });

Re: jQuery 4

#292
post #120

Earlier quoted context omitted.

I'm sorry what

I find it is a good idea, it allows developers to cleanly define how to structure elements without random divs sneaking in. It requires a strong design system and it probably makes it harder to use some web APIs but those can be reasonable tradeoffs

Speaking of which, is there a Tailwind CSS equivalent for React Native? I find passing `style` objects around (ala CSS Modules) to be a pain after using Tailwind for so long in web projects.

EDIT: Found one that's going v5 soon, looks nice. https://www.nativewind.dev/

Re: jQuery 4

#293

Earlier quoted context omitted.

Jquery does many things in one line that requires a couple lines of stdlib. Writing less code is what libraries are for.

Until you have to upgrade it and it bites you

jQuery, for as long as it's been around has had very few major releases, 4 now.. and very few breaking changes... hardly "biting" ... other than those sites that are injecting a half dozen different copies of jQuery from different modules, and who knows which one you're actually working with, let alone 3rd party payloads.

I mean, personally, I've mostly used React the past decade and any integration directly to the browser has been straight JS/TS... but I can still see how jQuery can be useful for its' conveniences.

Re: jQuery 4

#294

"jQuery?!?! We use J-jQuery" -Jack Borrough (Senior Javascript Developer)

I had a boss around 2008 or so... "Why are you guys talking about JavaScript? Can't you just use jQuery instead?"

Re: jQuery 4

#295
post #130

Earlier quoted context omitted.

body.qsa('.class').forEach(e=>): Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands of keystrokes. Then you can get creative with Proxy if you want to, but I never saw the need.

Please don't mess with native prototypes though.

I used to use prototype (and sometimes scriptaculous)... Then came IE8 and broke the world on me.

For anyone that didn't know, IE8 implemented native JSON.(parse/stringify) methods, and the second parameter is a hydrator/dehydrator... however, if you added custom properties/methods to Array or Object prototypes, they would throw an error you couldn't catch in JS... so to work around, you'd have to load the JSON library and use it under a different name, in ALL your code, because the native implementation was locked/sealed and couldn't be masked out.

Second most annoying IE bug was 5.0.0 and the old/new api's for dealing with select elements. New worked, old broken, have fun.

Re: jQuery 4

#296
post #138
post #136

Earlier quoted context omitted.

Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.

If you are an app or website developer, at least you won't break other's systems. But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name. Newer libraries start using that new standard method. You upgrade the libraries your website depends on, or add a dependency, and this new code happens to de…

We have a few oddly named methods for arrays and iterators because of the prototype and other libraries being very common.

Re: jQuery 4

#297
post #89
post #51

Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?" Anyway, jQuery always did the job, use it forever if it solves your problems.

I pretty much use HTMX and vanilla JS to solve most problems, when I use Django at least. Keeps things simple and gives that SPA feel to the app too.

I'm mixed on HTMX for going a step beyond interactive forms, it's fine... but much more and I find HTMX and server-side Blazor for that matter really janky... button events with a round trip to the server can just feel wrong.

FWIW, also hated the old ASP.Net Webforms round trips (and omg massive event state on anything resembling dialup or less than a few mbps in the early 00's).

I just wish that React and other SPA devs kept some awareness of total payload sizes... I'm more tolerant than most, but you start crossing over/into MB of compressed JS, it's too much. Then that starts getting janky.

Re: jQuery 4

#298

Earlier quoted context omitted.

I think it's a matter of taste and preference mostly, but I like Vue's overall design better. It uses JS Proxies to handle reactive state (signals, basically) on a granular level, so entire component functions don't need to be run on every single render — only what's needed. This is reflected in benchmarks comparing UI libraries, especially when looking at table row rendering performance. Their setup (component) func…

I tried proxy-based approaches before (in Solid) and I _also_ had a lot of problems with async processes. The "transparent" proxies are not really transparent. I understand that mixing declarative UI with the harsh imperative world is always problematic, but I think I prefer React's approach of "no spooky action at a distance". As for speed, I didn't find any real difference between frameworks when they are used corr…

I forgot to mention in my other reply, but if you find yourself needing to render a massive list performantly, check out TanStack Virtual. It's a godsend!

Re: jQuery 4

#299

Earlier quoted context omitted.

You can use Tanstack Query or Zustand for this in React. They essentially have a global state, and you can attach reactive "views" to it. They also provide ways to delay rendering until you have the data ready. Your example would look like: const id = useState(...); const numericState = useState(0); const q = useQuery({ queryFn: async (context) => { const data = await fetch(..., {signal: context.signal}); const deriv…

I've used React Query and Zustand extensively in my projects, and unfortunately Zustand suffers from the same issue in cases where you aren't dealing with async data. I'm talking about React state + data that's already available, but can't be used to initialize your store before the first render cycle. Here's how Zustand gets around this, and lo-and-behold: it requires React Context :( [1] (Look at how much boilerpla…

I think it might already be working like that? React now has concurrent rendering, so it will try to optimistically render the DOM on the first pass. This applies even if you have hooks.

There is no real difference now between doing:

  const [state, setState] = useState(42);
and:

  const [state, setState] = useState(undefined);
  useEffect(() => setState(42));
They both will result in essentially the same amount of work. Same for calculations with useMemo(). It was a different situation before React 18, because rendering passes were essentially atomic.

Re: jQuery 4

#300

Earlier quoted context omitted.

I've used React Query and Zustand extensively in my projects, and unfortunately Zustand suffers from the same issue in cases where you aren't dealing with async data. I'm talking about React state + data that's already available, but can't be used to initialize your store before the first render cycle. Here's how Zustand gets around this, and lo-and-behold: it requires React Context :( [1] (Look at how much boilerpla…

I think it might already be working like that? React now has concurrent rendering, so it will try to optimistically render the DOM on the first pass. This applies even if you have hooks. There is no real difference now between doing: const [state, setState] = useState(42); and: const [state, setState] = useState(undefined); useEffect(() => setState(42)); They both will result in essentially the same amount of work. S…

Ah great point, I need to give this another shot and confirm. I only switched from 17 to 19 in the last few months here.
Post reply on HN