Object layout for searching?

JavaScript
1

I am struggling to stay motivated with JavaScript, So thought I’d set my self a small project.
the plan being to have a page where i can search for a tool in my kit and it will display where it is and what it is, and to be able to search a container and it to show all tools in container.
Have started writing out the tools in object but realized may have done this the hard way. Figured would be better to ask what would be seen as more standard/better practice.
currently have it set as

var object1  {
container1{
colorcode: 'blue'
tool1: {
 contains:[],
   brand: '',
   ordering: ''
},
tool2{
}
},
container2{
tool1{},
tool2{},
tool3{}
}
};

would i be better off removing “tool*” from “container” and adding it as a part of the tool object eg:

tool1: {
colorcode: 'blue',
contained: container1
 contains:[],
   brand: '',
   ordering: ''
},

any help/suggestions or links to articles would be much appreciated.

if you need a clear idea of my layout

2

i added html to show what i want to achieve in the end, It may even be useful to me after lockdown lol.
am i aiming a bit too high?

3

You’ve got the right idea, and second one is better.

You have tools, with some properties.
You have containers which contain tools.

First one is very fragile and not very useful: every time you need to change something you need to drill into a single huge object and update it. The connections between each discrete {thing} should be weak, rather than trying everything together tightly.

You don’t need to have each tool say what it’s contained in, the container object can just have an array of tools that it contains. This possibly models reality slightly better: tools have no connection to what they are contained in (although need to be careful trying to model reality too closely, it can be a trap, code and data aren’t reality).

However, not having bidirectional connections (container has tools, tools live in container) can start to cause issues/annoyances as you add more and more tools, so to mitigate you can do what you have in you:

  • add an ID field to each tool. Then the container has an array of tool IDs.
  • add an ID field to the container. Each tool says which container it belongs to
  • take out the direct linking of IDs in the tools/containers themselves, and add another object which is just a map of tool ID → container ID, then look up in that when you want to check which container a tool is in.
  • same, but inverted (map of container ID → [array of] tool IDs) which gives you lookup in the other direction

All may seem to include a lot of redundancy, repeating things, but it makes things much simpler in the long run, as you may have a lot of tools and many containers.

The thing you are writing here is a relational database. It’s just in objects, but same rules apply: there are decades-old solutions to most of the issues you’ll have

1 Like
4

To add to what Dan said, I suggest you to keep this version of your code also. Fork this code and change the structure in that, just so you can see for yourself what works and what doesn’t.

It may well happen that you don’t end up creating all that many containers or even add tools that frequently, and therefore might not need all the stuff that comes in a relational database.

Since you asked for articles, I suggest you look into ER models.

Your ER model might change depending on your requirements. Whether you need to add data more frequently, or search more frequently. Will you be searching by id, name or something else etc.

Then you’ll need to code up your ER model. Generally this is done using a Database Management System. But you could do it using objects in minor cases I suppose (I’ve never tried).

Just keep the both versions of code(one with just the current object, and the other where you make further changes to the data), because it’ll allow you to actually see what worked and why.

2 Likes
5

Just to clarify slightly, I should have said it resembles a relational database, and that the same rules apply. You’re fine working with objects atm. It opens you up to general ideas about how you structure and handle data (none of which are very complicated!). It’s just knowing where to look for solutions, and most of those are described in literature relating to databases. It’s a really good, simple project, doing it will teach you a great deal, and you can keep iterating on it to the nth degree.

I dunno if I’d recommend much specific – I think you’ve got the right idea at the minute so I would keep going and see what you can build using that & ask when you run into problems (they may have nothing to do with data, rather how you’re showing it)

1 Like
6

thanks Guys, I’m thinking ill continue with as is for now and “fork” it and change the structure afterwards to see and learn the difference.
I really appreciate the guidance thank you :slight_smile:

1 Like
7

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.