Dusty
In the course of working on a tree-like data structure, I have designed a struct for each node in the tree. Since there are only 5 fields in each node, and all nodes have the same 5 fields, using a struct made sense to me.
However, one of the %Node{} struct fields contains the children of the node, which is a list of %Node{} structs, each of which can have its own children, and so on.
Given the challenges of accessing nested structs, I am beginning to question my original decision to use a struct instead of a map. I see that there are a number of posts already on how to access nested structs, but I’m still left asking: What does a struct really offer me here? Basically, it offers me the ability to limit the keys for each node. But is that a worthwhile tradeoff, given that the number of nested levels could be very high? Is it really a problem to just use a map?
The nature of the code is such that reaching down many levels at once is unlikely to be needed. For the most part, the tree will be walked one level at a time, but it will frequently be necessary to match on or modify fields in the node’s children (1 level down). It seems that the risk of unintended fields on the struct is perhaps not worth the complexity of using a struct in the first place.
Thoughts?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
MrDoops
Depends - a couple I’d things to try:
You could try wrapping/adapting an existing graph data structure like libgraph or digraph maybe using your existing
%Node{}struct as a vertex. There are functions you can you use to access and travel the graph.But you might get somewhere useful quicker with Kernel.get_in/2.
Most Liked
NobbZ
Not beeing able to use
Accessout of the box for yourNodestructs is actually a feature in my opinion. This enables you to come up with an implementation ofAccessthat would make even more sense for a tree.NobbZ
You can’t have circular references in immutable data structures.
You can of course simulate them using a flat datastructure and mentioning IDs.
dimitarvp
You can draw inspiration from my extremely amateurish Trie library which was basically my first ever Elixir code somewhere back in 2016, here: trie/lib/trie.ex at master · dimitarvp/trie · GitHub. This demonstrates a basic
Access.getimplementation. Once your struct has that you could easily useget_inwith instances of the struct as parameters.Also check out
Accessdocs. You need only implement a few functions to be able to useget_inandput_in.