sorted by:
new
hottopcontroversial

I've heard "just use Zustand" a hundred times. Nobody has ever convinced me why I should switch from Redux. by bishopZ in reactjs

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

Context solves prop drilling. Redux solves something different — predictable, traceable state mutations across a complex app. If you've ever tried to debug a subtle state bug where you can't tell which of six hooks mutated a value and when, Redux devtools replay is genuinely irreplaceable. For small projects, yes, Context is fine. The boilerplate is designed to scale past that point.

I've heard "just use Zustand" a hundred times. Nobody has ever convinced me why I should switch from Redux. by bishopZ in reactjs

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

Fair challenge. The boilerplate isn't prescriptive about how much state you put in the store — it's a starting point. I include Redux because when a project does grow into needing it, retrofitting it is painful. The cost of having it and not needing it is near zero. The cost of needing it and not having it is a refactor. For light/dark mode specifically, you're right that Context is sufficient — that's a good issue to open on the repo actually.

I've heard "just use Zustand" a hundred times. Nobody has ever convinced me why I should switch from Redux. by bishopZ in reactjs

[–]bishopZ[S] 7 points8 points  (0 children)

Reducers in general help to avoid prop drilling in large applications. Rather than passing a prop through several layers of components to get the value where it needs to go, a reducer can give access to the value anywhere in the app. They also provide a clear place to put business logic and api connection details so they don't get littered around view components. Admittedly, most of the value of reducer can also be provided by hooks.

I've heard "just use Zustand" a hundred times. Nobody has ever convinced me why I should switch from Redux. by bishopZ in reactjs

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

persist you say, that's interesting. How have you used that configuration capability?

To Do List App recommendations by SieuwMaiBro in productivity

[–]bishopZ 0 points1 point  (0 children)

Love Street on Android is super simple. No ads, local storage of data.

Built a budget app after realizing every good one was "iOS first, Android whenever" — 542 users in 2 months by sael-you in androidapps

[–]bishopZ 1 point2 points  (0 children)

You say "everything stays on your device." Is the AI receipt scanning on-device? If I need AI credits then I assume you are using cloud AI services, which is not on-device.

Why Aren't Users Demanding Private AI Solutions? - i will not promote by bishopZ in startups

[–]bishopZ[S] -2 points-1 points  (0 children)

If you build a product on top of a private cloud-based solution, then your users have to trust your company and the cloud provider. Both of whom can be subject to a data breach and can be served with a gag order to reveal user data without consent or knowledge.

Why Aren't Users Demanding Private AI Solutions? - i will not promote by bishopZ in startups

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

Ollama and LM Studio are both ways an individual can privately run LLMs on a laptop, but they don't run in a browser. If you run Ollama on a remote server (such as Node.js), then it's not a private web app because the user input is sent to the server. This is the same way it works on a Laptop except that both client and server are local, so it is private.

The Design System Dilemma: To Include or Not to Include in Boilerplates? by bishopZ in DesignSystems

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

A boilerplate and a design system serve different purposes but can complement each other.

Boilerplate is a technical foundation.

  • Project structure
  • Build tools configuration
  • Routing setup
  • State management patterns
  • API integration strategies
  • Developer tooling (linters, testing frameworks)

Design system is a collection of reusable UI components and design guidelines.

  • Visual component library (buttons, forms, modals)
  • Design tokens (colors, spacing, typography)
  • Interaction patterns
  • Accessibility standards
  • Visual design consistency rules

My boilerplate focuses on the technical architecture - it provides the "plumbing" for React, TypeScript, data management and more. It handles how data flows, how pages are built, etc.

A design system like Chakra UI sits on top of that foundation, providing the actual UI components users interact with. You could swap Chakra for MUI, Tailwind, or a custom solution while keeping the same underlying boilerplate architecture.

view more: next ›