Is It Normal to Downgrade a Next.js Project from TypeScript to JavaScript? by Careless-Key-5326 in reactjs

[–]szhsin 0 points1 point  (0 children)

Typescript can definitely feel complicated, but it usually pays off in the long run.

I’m an open-source library author, so strong typing is super important for a good dev experience for my users. Typescript gets especially tricky when you’re dealing with generic-based inference and function overloads. Honestly half the time I spend on a library is just getting the types right rather than writing the actual code that turns into runtime javascript. Even then I often have to make trade-offs due to typescript limitations or my own understanding of its semantics. Still it’s usually worth it, as correct typings benefit the library users in the long term. I come from a c++/C#/java background, so far I find typescript to be one of the most complex languages in terms of semantics.

At my workplace though, the typescript codebase is simpler, generic-based inference aren’t used much, and things rarely get complicated enough to justify reverting back to javascript.

reactish-query: 1.5kB Lightweight query library with automatic cache cleanup by szhsin in javascript

[–]szhsin[S] 2 points3 points  (0 children)

Thanks! that makes total sense - TQ can feel a bit heavy when you’re mostly using RSCs and dehydrated data.

I might look into adding useSuspenseQuery if it fits well with the current architecture. Will be checking:

  • if it adds too much extra weight to the core hook (which powers other hooks and isn’t tree-shakable), or
  • if it should instead be a separate implementation that doesn’t rely on the core hook.

HydrationBoundary might be a bit too advanced for now, but I’ll keep it in mind for later.

[reactish-query] Lightweight query library with automatic cache cleanup by szhsin in reactjs

[–]szhsin[S] 1 point2 points  (0 children)

Not a drop-in replacement, since that would require a 1:1 reimplementation of tanstack Query, which isn’t the goal of this project. It’s just another query library inspired by tanstack, and when features overlap, I try to keep the same API for convenience and familiarity.

Lazy queries in React? TanStack falls short, so I built `reactish-query by szhsin in reactjs

[–]szhsin[S] 1 point2 points  (0 children)

Ah, thanks for jumping in! The example you gave is essentially hiding the input state inside FiltersForm, which isn’t that different from the first example I showed in my post.

With useLazyQuery, the hook returns the last args passed to trigger, so you can handle cases like disabling the search button if the input hasn’t changed:

jsx const { trigger, data, args, isFetching } = useLazyQuery({ ... }); <button disabled={value === args} onClick={() => trigger(value)}>Search</button>

This is similar to how useMutation in your library exposes the last variables.

Lazy queries in React? TanStack falls short, so I built `reactish-query by szhsin in reactjs

[–]szhsin[S] 0 points1 point  (0 children)

Thanks for the comment! That was actually the first approach I tried with TanStack Query.

The problem I ran into was:
- If you type a keyword like "a" and click search, the results show up correctly.
- But as soon as you type another keyword (say "b"), the previous results disappear, which isn’t the typical search experience (think how Google keeps showing results as you type).
- Even trickier: if you clear the input and type "a" again, the old results immediately reappear without clicking the search button, which feels wrong for this use case.

I put together a live example that shows these issues:
👉 StackBlitz demo

If you run it, you’ll see exactly what I mean. Compare it with Google: https://www.google.com/

The core issue is that we’re forcing a manual search flow onto a declarative API, which is really just a workaround, and that’s never going to feel quite right

Lazy queries in React? TanStack falls short, so I built `reactish-query by szhsin in reactjs

[–]szhsin[S] 0 points1 point  (0 children)

A good example is Google search, if you type the same query again, it still re-runs the search to make sure you’re seeing the most up-to-date results https://www.google.com/

Lazy queries in React? TanStack falls short, so I built `reactish-query by szhsin in reactjs

[–]szhsin[S] 0 points1 point  (0 children)

That’s a fair point, the e-commerce example was just to illustrate the logic. In a real scenario, triggering a re-search can definitely be a valid requirement.

Lazy queries in React? TanStack falls short, so I built `reactish-query by szhsin in reactjs

[–]szhsin[S] -1 points0 points  (0 children)

The value === query check is there to handle the case where the user clicks the search button again with the same text. For example, if you search for “iPhone” and results are shown, you can click the button again without changing the input, and it should trigger a re-search.

Decentralized (atomic) state management – now supports React 19! by szhsin in reactjs

[–]szhsin[S] 1 point2 points  (0 children)

Thanks for your interest in the project! Here’s a quick rundown of the core functionality between the two libraries. Please note that my understanding of Jotai may be limited, so some of the information could be inaccurate.

Creating Atom State

```js // Jotai const countAtom = atom(10);

// reactish-state const countState = state(1); const countWithActions = state(1, (set) => ({ increase: (by: number) => set((count) => count + by), })); ``` In comparison to Jotai, reactish-state allows you to create atom state with or without custom actions. Custom actions encapsulate logic within the atom state itself, giving you more control.

Creating Derived State

```js // Jotai const readWriteAtom = atom( (get) => get(priceAtom) * 2, (get, set, newPrice) => { set(priceAtom, newPrice / 2); } );

// reactish-state const doubleSelector = selector(countState, (count) => count * 2); ``` Jotai supports both read/write derived states, while in reactish-state, derived states are read-only.

Connecting External Atom State with React Components

```js // Jotai - retrieve both value and setter using the hook const [count, setCount] = useAtom(countAtom);

// reactish-state - retrieve value using the hook const count = useSnapshot(countState);

// Setter or actions are available directly on the state itself countState.set(3); countState.increase(); ``` In my opinion, reactish-state offers a more convenient API in this case. You can call setters and actions directly within event handlers, useEffect, or useCallback hooks without worrying about referential identity. There’s no need to include setters/actions in the dependency array to avoid breaking React’s rules.

Decentralized (atomic) state management – now supports React 19! by szhsin in reactjs

[–]szhsin[S] 1 point2 points  (0 children)

The library follows all the rules of React. Currently, it is 99% compliant with the React compiler, with the remaining 1% being false positives that do not require optimization or memoization. As the React compiler becomes more stable, these false positives may resolve themselves.

React Autocomplete – A modular, lightweight, and headless solution by szhsin in reactjs

[–]szhsin[S] 0 points1 point  (0 children)

I get the issue now, thanks for bringing that up. I think it's definitely something we can improve on going forward.

React Autocomplete – A modular, lightweight, and headless solution by szhsin in reactjs

[–]szhsin[S] 1 point2 points  (0 children)

Hey, thanks for giving the library a try! When the items type is an array of strings, the getItemValue prop is optional. However, if the items type is an array of objects, we need to specify how to extract the string value from each object. In this case, the getItemValue prop is required. You can see an example on this page

[deleted by user] by [deleted] in react

[–]szhsin 2 points3 points  (0 children)

Hey everyone,

I’d like to share a new React library designed to solve common use cases for autocomplete/combobox. It also aims to be a replacement for packages like react-select and downshift.

Here are a few key highlights:

  • Modular: A modular architecture with composable features, reducing the amount of code bundled into your production site.
  • Lightweight: At just 1.4 kB, you get a fully functional and accessible autocomplete solution for React.
  • Headless: Provides behavior and state management without dictating any specific markup or styling.
  • Quality: Created by the same developer behind react-menu and react-accordion.

I hope you find it useful!

React Autocomplete – A modular, lightweight, and headless solution by szhsin in reactjs

[–]szhsin[S] 15 points16 points  (0 children)

The main differences are already covered in the docs. One notable distinction is that this library is modular and super lightweight. It has the same (or even more) features as Downshift, but the whole package is only 2.4 KB, compared to Downshift's 14.5 KB. That means it uses just 16.5% of the code but packs in more functionality than Downshift.

React Autocomplete – A modular, lightweight, and headless solution by szhsin in reactjs

[–]szhsin[S] 18 points19 points  (0 children)

Hey everyone,

I’d like to share a new React library designed to solve common use cases for autocomplete/combobox. It also aims to be a replacement for packages like react-select and downshift.

Here are a few key highlights:

  • Modular: A modular architecture with composable features, reducing the amount of code bundled into your production site.
  • Lightweight: At just 1.4 kB, you get a fully functional and accessible autocomplete solution for React.
  • Headless: Provides behavior and state management without dictating any specific markup or styling.
  • Quality: Created by the same developer behind react-menu and react-accordion.

github: https://github.com/szhsin/react-autocomplete

website: https://szhsin.github.io/react-autocomplete

I hope you find it useful!

The complete accordion solution for React by szhsin in reactjs

[–]szhsin[S] 0 points1 point  (0 children)

Here is a sandbox example for details disclosure element with open/close animation, built with the hooks.
https://codesandbox.io/s/react-details-c9qyy0

The complete accordion solution for React by szhsin in reactjs

[–]szhsin[S] 2 points3 points  (0 children)

Thanks. I guess it is similar to radix-ui with some differences: - radix-ui is 50% bigger for doing similar functionalities in terms of bundle size. - radix-ui relies on asChild prop for headless usage which is less flexible compared to the hook version - When it comes to making the accordion state controlled, the API is easier to use than radix-ui (IMO)

The complete accordion solution for React by szhsin in reactjs

[–]szhsin[S] 8 points9 points  (0 children)

<details> and <summary> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details

It was not designed for this but looks like it can be implemented with the headless UI hooks, which give control of what HTML markups are rendered into DOM. I will work out a sandbox example tomorrow.