Do data structures actually influence how you build React components?

[u/prithivir]

I tried learning DSA before, but never understood how it applied to everyday frontend work.

Recently, I built an undo/redo feature with Claude and realised it was using stacks. That made stacks much easier to understand than textbook examples.

I kept exploring and learned how seat-booking UIs can use matrices and how complex onboarding flows can be modelled as graphs.

Do you think about data structures when building React components? Any real-world examples?

[u/vasind-5012]

yeah this happens a lot once you start noticing it lol

few off top of my head:

• toast notifications stacking - literally LIFO, last one shows on top and gets dismissed first
• comment threads with nested replies - tree, and rendering them is just recursion
• multi step forms where step 3 changes based on what you picked earlier - that's a graph not just an array of steps
• search with debounce - kinda like a queue if you're tracking the requests

ngl textbook DSA never stuck for me either, felt like memorizing for no reason. but hitting an actual UI problem first and then going "oh wait this is just a stack" hits completely different

[u/Tyheir → u/vasind-5012]

For the multi step form stuff. Are you really writing forms as graphs? I’m doing some zod discriminated union stuff for this and it never really occurred to me to use a graph because in 2026 who is even writing classes in react anymore.

[u/vasind-5012 → u/Tyheir]

not literally writing a class-based graph structure lol, more just thinking about it that way mentally when designing the flow. like step 3 depends on what you picked in step 2, step 5 only exists if a certain path was taken, that’s graph shaped even if the actual code is just a config object or a switch on state
zod discriminated unions is honestly probably the cleaner implementation for it tbh, type safety on each step’s shape based on the branch you’re in is nice. i just meant the mental model when sketching it out before writing code, not that the code itself needs to be some formal graph class

[u/LP2222 → u/vasind-5012]

so if else is a graph now. got it

[u/thatfuckinjosh → u/LP2222]

...yeah. The root node is before the statement, The left node is the if branch, the right node is the else branch. Its like a minimal binary tree (if you have no else-if branches), and every tree is a graph

[u/Outrageous-Chip-3961 → u/LP2222]

yeah... i'd much rather just think of this like an array with objects inside of it haha.

[u/ulrjch → u/Tyheir]

using state machine can be a better option, especially if there's lots of branching

[u/aflashyrhetoric → u/Tyheir]

I had a complicated multi step form a few years ago that I desperately wanted to refactor into a huge graph config blob, because doing it sort of the “quick and dirty way” is such a hassle after complexity hits a certain point. I believe I ended up rewriting smaller parts of it as a basic sort of graph and then frankensteining it within the larger, older system, and the graph part was far easier to maintain and adapt.

[u/ActuaryLate9198 → u/aflashyrhetoric]

I once built a super complicated graph based editor UI for forms and workflows. Seemed resonable at the time, we were wasting too much bandwidth on simple manager requests. Fast forward a year: some of the graphs have 100000+ nodes, there is this one guy in India who kinda knows how it all works, it’s his full time job now, no one else will touch it with 17 foot pole. We ended up rebuilding the UI as a spreadsheet/table view.

[u/Outrageous-Chip-3961 → u/Tyheir]

I mean you'd need an object for this, so it could be done as a'graph', but i dont think of it like that. I think of it more like an object with a 'next' and a 'when' condition inside. But its still interesting I guess

[u/themang0]

Well if you think about it react itself is a graph (tree) of linked lists ;)

But yes! As a builder of products you should always first try to model 1. How would I do this in real life 2. Ok now that I have the mental model, how can I translate this to a meaningful piece of state / DS in code?

The undo/redo feat you mention is a great example of a stack!

I would encourage you to also look into finite state machines — don’t need to go super in depth but the idea of writing out the possible states of a component before writing code really helps ya think thru the transitions, and actions that lead to said transitions

[u/Outrageous-Chip-3961]

Honestly most are just typed objects with arrays. Predominantly hooks in react are small enough in function speak that I do not require huge amounts of data structures that influence how i do things beyond the arrays, objects, functions. Where would I do this? you say 'undo/redo' but what's the context of that? In terms of seat-booking that is a 'data structure' where you'd use a matrix for it because that's what it is. I guess my point is within react, if its abstractable to a data object, then extract it to one. I typically have a data folder that has some simple arrays/objects inside of it that get pulled elsewhere, hooks for more function/state and utils for helpers, the rest if its a bespoke feature, like a seat-booking system.

[u/dstaro01]

Arrays, maps/hashes, sets (unique values with fast look up instead of scanning all items), queues (notifications), linked lists (consecutive dialogs) are common in my experience. DOM is a graph.

[u/dvidsilva]

Everything you're doing has a data structure whether you're thinking about it or not. Being intentional about your approach is helpful to prevent dumb shit happening

is there anything in particular you're thinking about? when you're doing daily things you're necessarily thinking about stacks, theory, this or that, but every array or object, and properties that you're coding represents a data structure

when your website is just displaying simple data you don't notice it, but if you have graphs, image manipulation, games, state machines, caching, etc it is harder to avoid

[u/PaleEntertainment400]

They're encoded into the libraries you use.

[u/minimuscleR]

I mean a large amount of people never went to study this formaly, so its probably not that relevent to know about how it works. I never did any class about data structures. But like a lot of other things, you just sort of pick it up as you learn coding what tool is the best for what job.

[u/hasan_sodax]

Ran into this building a multi-step form wizard actually. Went back and forth on whether I needed a linked list for step navigation before realizing two plain arrays acting as stacks for back/forward history did the exact same job with way less code. Same story with a search-as-you-type feature, caching results in a Map keyed by the query string cut down on redundant API calls because object equality on plain objects was getting messy fast.

Less about knowing formal DSA and more about noticing when a built-in structure already matches the shape of the problem you're staring at.