Three Weeks in Review:

Turns out I don’t love mandatory blogs. What? Anyways, here are a few things I learned about and thought were interesting these past three weeks.

Spreading props into React components

Until now, if I ever needed to pass an object into a React component, I would do as follows:<MyReactComponent myObject={myObject} />

To access the data, in MyReactComponent: this.props.myObject[A_KEY_IN_MY_OBJECT]

My partner in a project I’m currently working on showed me a great way to improve the whole process:

<MyReactComponent {…myObject} />

This is something that’s just really cool about coding. I’ve known how to spread arrays and objects for — (Oh right, it’s only been about two months) — But I feel like I’ve known how to do that forever. Nevertheless it never occurred to me that I could use that method here, but when I saw it, it made so much sense. Besides for shortening the code when passing data in, taking data out on the other end is also easier: this.props[A_KEY_IN_MY_OBJECT]. I suppose this would not be the best practice if multiple objects had to be passed into the same component. That might lead to two or more objects having the same keys in them, which would overwrite each other, but on a small scale, I think it’s brilliant.

Managing many tables in a database

Thus far into my coding career, I’ve only dealt with databases that had up to three tables. Now that I have a modern understanding as to how data and relationships are to be handled in the backend, the way I save data structures are very different. Arrays in old-terms, are each their own tables in modern-terms. That leads me to creating multiple tables, more than just three. We are talking 6 or more tables, which could easily be overwhelming to think about. How can so many relationships exist, and in a way that is understandable to work with and debug?

I spent a lot of time drawing out on paper, on Miro, with index cards, etc… It can get REALLY confusing really fast.

The solution I found for myself was to break down all the table-relationships down to the familiar 3-table arrangement I worked with when I learned about relationships. Using a barbershop example

Barber — < BarberStation > — Station

A barber can have many stations where they work, and one station can have many barbers. They are connected through BarberStation entries. To handle managers overseeing the ‘assignments’ — and another association, I would write it out on another line, for example:

BarberStation — < BarberStationManager > — Manager

One manager can oversee multiple assignments of Barber to Station (BarberStation entries), through BarberStationManager entries.

While I thought I would benefit from seeing a 2-D layout of my tables and associations, this 1-D (or 1-liner) option made much more sense to me, and having many tables is much less daunting to me.

Saving Date/Time in the Backend

In a past project, my partner and I had a difficult time managing saved dates in the backend and passing it as usable data to the frontend. Check out the blogpost my partner Isaac wrote about what we learned trying to work that out. In short, the issue we had was that our database (Ruby/Rails) could not pass a usable instance of a DateTime to our frontend (JS).

In my current project, we tried a different approach. We accepted the fact that the only thing we could expect from the backend was a string that correlated to the DateTime we had saved. However, in Ruby and JavaScript, the constructor for a new instance can accept a string as an argument. The cleanest way that we found was to convert the string to a native instance of DateTime, and then all the methods are available to us. Any formatting we want is now a matter of the right method and passing the right arguments, and there’s no need to try splitting (.split()), splicing(.splice()), or indexing on a string at all. Much pleasure all around :).

Stay vertical everyone!