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!
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.
I'd go with import { toValue } from "vue"; export const optionalProps = (input) => { if (!input || typeof input !== "object") return {}; const entries = Object.entries(input); return entries.reduce((acc, [key, value]) => { const resolvedValue = toValue(value); if (resolvedValue !== null && resolvedValue !== undefined) { acc[key] = resolvedValue; } return acc; }, {}); }; That way you can pass in as many optional props as you want and additionally, it will handle any type of value (ref, reactive, computed or primitive).
hmm, I think it need to be `return { [name]: value.value }` (name in a square brackets). because otherwise it will always create a key with name "name" but not the string value in a variable `name`
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.
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!
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.
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.
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.
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!
not truthy, but not undefined (or not null, depending on whats needed)
I normally pass everything and let the backend do its thing
Good video my man, keep it on
...opt('favoriteColor', favoriteColor)
function opt(key, ref) { return ref.value ? { [key]: ref.value } : {} }
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.
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
I'd go with
import { toValue } from "vue";
export const optionalProps = (input) => {
if (!input || typeof input !== "object") return {};
const entries = Object.entries(input);
return entries.reduce((acc, [key, value]) => {
const resolvedValue = toValue(value);
if (resolvedValue !== null && resolvedValue !== undefined) {
acc[key] = resolvedValue;
}
return acc;
}, {});
};
That way you can pass in as many optional props as you want and additionally, it will handle any type of value (ref, reactive, computed or primitive).
hmm, I think it need to be `return { [name]: value.value }` (name in a square brackets). because otherwise it will always create a key with name "name" but not the string value in a variable `name`
It's a good thing to learn something new.
Nice [[]]
damn nice. thanks
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
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
Not reflection. Also, the payload must be serialized, if sending via REST - remove null values during serialization.
I thought JSON serializing (if that's what happens) removes `undefined` values but keeps null
Yup, but you can supply a transformer function to drop nulls along the way as well. Might as well do it all in the single loop of serialization.
Just send everything and let the backend logic for favourite colour deal with the empty value - it has to check the value anyway.
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.
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
Huh, I thought this was just normal js object manipulation....
Its called “spread operator” not “rest operator” 😄 sorry it started to annoy me a bit after you said it multiple times haha
you should
return {
[name]:value.value
} // or it wont work
Like 100
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.
That is only applicable if you're only having one value named favcolor. If it's multiple one's his approach is sure valid.
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
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.