I feel like a simpler way to solve this problem is to make a function that takes an object, and returns a new object with only the keys on it that are truthy. But I like the creativity!
Nice exploration. But over time you come to a realization that simpler is better, especially when you're working in teams. The abstraction you just made is not easily understandable and that might come to bite you in the future. Happens to me sometimes. That doesn't mean you stop doing that. Do it, you're mastering the language.
Love that you're learning and having fun :) this video made my brain hurt though ... this is a tutorial on what _not_ to do. Especially using reflection for something that can be solved with a standard. Clever code != Good Code. Bad habits all over the place.
You could have solved it with something like ...(favcolor.value && { favcolor: favcolor.value } its shorter than what you had and easier to reason with than what you later developed. But yes its a nice discovery you made regarding reflection.
It's one way of doing this and it's not completely wrong. However, I think you should utilize the undefined value as is instead of this additional logic. JSON.stringify removes undefined values from an object, so just run every object through JSON.stringify before sending to the server. This is the way axios handles for it, for example, and in my opinion it's the correct use case for undefined values. And you kind of need to stringify the request data anyways, since there is no concept of data types in the HTTP layer, it's just bytes being parsed on both ends. In fact, JSON doesn't even contain undefined value, and null should be used to represent an "empty" value. So tl;dr: prefer to use undefined to omit properties, null to represent empty values.
I feel like undefined value should be returned and checked by the API (if the API your are dealing with is correctly setup) not by the client because you are doing work that should be done anyway by the server, so either you are doing twice the work, or the server can be corrupted by a malicious user. Anyway cool to see you are exploring the langage and you had fun!
You can do it more simply with function submit() { const payload = Object.fromEntries( Object.entries({ name, email, favoriteColor }) .filter(([_, ref]) => ref?.value != null) .map(([key, ref]) => [key, ref.value]) ); post(payload); } Some of the utility libraries like Lodash/Underscore.js also give you access to a `mapValues` type utility function that does the same as above, but more efficiently and less code on your part. `zip`/`unzip` are also functions in these utility libraries that help a lot with this kind of object transformation and go tegether well with `fromEntries` / `toEntries`.
@@AkioJunichiro Which is why I mentioned utility libraries. In this example however, the number of loops doesn't matter. If it were a bigger object, then sure, but for something with
I was so invested in this video only to discover the most basic and commonly used pattern for creating objects. No hate though, I liked the way you explained. It would help out beginners I guess. If you watch any beginner level tutorial about javascript objects, you will find this pattern being explained.
Just send everything and let the backend logic for favourite colour deal with the empty value - it has to check the value anyway.
Also you have error in your opt function, it should return {[name]: value.value} in your case.
You are correct
Nice tip, though this makes me wonder how many people have read a book about javascript
I feel like a simpler way to solve this problem is to make a function that takes an object, and returns a new object with only the keys on it that are truthy.
But I like the creativity!
i would always submit all values even when null/undefined
Careful with sending non-nullable values to a PHP backend.
@GeneraluStelaru if it's not nullable, the validation will fail on the php side
...opt('favoriteColor', favoriteColor)
function opt(key, ref) { return ref.value ? { [key]: ref.value } : {} }
Nice [[]]
Nice exploration. But over time you come to a realization that simpler is better, especially when you're working in teams. The abstraction you just made is not easily understandable and that might come to bite you in the future. Happens to me sometimes. That doesn't mean you stop doing that. Do it, you're mastering the language.
Teams should RTFM i guess
Love that you're learning and having fun :)
this video made my brain hurt though ... this is a tutorial on what _not_ to do. Especially using reflection for something that can be solved with a standard. Clever code != Good Code. Bad habits all over the place.
Not reflection. Also, the payload must be serialized, if sending via REST - remove null values during serialization.
You could have solved it with something like ...(favcolor.value && { favcolor: favcolor.value } its shorter than what you had and easier to reason with than what you later developed. But yes its a nice discovery you made regarding reflection.
It's a good thing to learn something new.
Just [r]: r.value wouldn’t work? [r] takes the name of the r variable and it can be used as an object key here
[r] wouldn't be the name of the variable, it would try to take the whole value of r, and use it as the key for the new object
Its called “spread operator” not “rest operator” 😄 sorry it started to annoy me a bit after you said it multiple times haha
Huh, I thought this was just normal js object manipulation....
It's one way of doing this and it's not completely wrong. However, I think you should utilize the undefined value as is instead of this additional logic. JSON.stringify removes undefined values from an object, so just run every object through JSON.stringify before sending to the server. This is the way axios handles for it, for example, and in my opinion it's the correct use case for undefined values. And you kind of need to stringify the request data anyways, since there is no concept of data types in the HTTP layer, it's just bytes being parsed on both ends. In fact, JSON doesn't even contain undefined value, and null should be used to represent an "empty" value. So tl;dr: prefer to use undefined to omit properties, null to represent empty values.
I feel like undefined value should be returned and checked by the API (if the API your are dealing with is correctly setup) not by the client because you are doing work that should be done anyway by the server, so either you are doing twice the work, or the server can be corrupted by a malicious user. Anyway cool to see you are exploring the langage and you had fun!
cool
You can do it more simply with
function submit() {
const payload = Object.fromEntries(
Object.entries({ name, email, favoriteColor })
.filter(([_, ref]) => ref?.value != null)
.map(([key, ref]) => [key, ref.value])
);
post(payload);
}
Some of the utility libraries like Lodash/Underscore.js also give you access to a `mapValues` type utility function that does the same as above, but more efficiently and less code on your part. `zip`/`unzip` are also functions in these utility libraries that help a lot with this kind of object transformation and go tegether well with `fromEntries` / `toEntries`.
4 loops under the hood tho
- fromEntries
- entries
- filter
-map
his the solution 2 loops
-entries
-spread operator
@@AkioJunichiro Which is why I mentioned utility libraries. In this example however, the number of loops doesn't matter. If it were a bigger object, then sure, but for something with
Like 100
I was so invested in this video only to discover the most basic and commonly used pattern for creating objects.
No hate though, I liked the way you explained. It would help out beginners I guess.
If you watch any beginner level tutorial about javascript objects, you will find this pattern being explained.