I use TypeScript in this example just because it's easier to be explicit about return types, expectations, etc ... and because I enjoy TS! However, proxies are widely available in JS, and you don't need to be using TypeScript to give this a try. I guess you won't get the editor hints for the `find` functions, but everything else will work.
This is how tRPC works. You define functions on the server, and tRPC uses proxies to make it seem like it's available on the client, with type-safety and all, and internally handles serialising the call over HTTP. It's pretty neat.
Nice! Years ago I worked for an employer that was creating metrology lab automation software, and I was responsible for the project since I'm a former calibration tech, metrologist, and dev for 35+ years. The project was using node-red to allow end-users to create automated calibration procedures that would either ask the user for input during the calibration or directly acquire the data from hardware, perform some checks on or calculations on the data, make a pass/fail decision, and store the result(s). However, node-red was not 100% up to the task, since there are fundamental parts of the internals that they don't expose. So, I started by forking node-red and customizing it to our liking, but that turned into a maintenance nightmare, and we quickly realized that altering node-reds behavior at runtime was the best approach. So, I started using Proxies to trap internal node-red calls, altering either the data going in, out, or sometimes both, depending on the needs. Anyway, thanks for bringing up this somewhat lost part of JS!
Trpc is using proxies... specifically recursice proxies to keep track of all the nested property access you do and convert that to an id that is passed to the trpc router to call the proper method on it. Pretty interesting
For anything that isn't a getter/setter (maybe getter and setter as well, not sure how that interacts with Object.keys) you can just map over the keys and create the object yourself or am I missing something?
Everything state related in Vue is a proxy, that's why you do not need to use callbacks for mutation in Vue, you just mutate state directly, render micro task is created automatically
Unless you're developing a library with very tight user experience constraints, I don't think proxies should be touched. It's the worse thing for readability, I've ever interacted with in JS
Proxies are actually a design pattern. It always felt weird to me that the language has a construct that represents a pattern, and feels badly implemented for consuming it honestly. Why JS had to do this? Don't know, but I think implementing the pattern yourself is way cleaner and easy to follow than using the native construct.
@@Guergeiro ah, sorry, I can't control that youtube behaviour. If you still have the link, wanna email it to me? you can find my email on my website, linked in the video description.
I use TypeScript in this example just because it's easier to be explicit about return types, expectations, etc ... and because I enjoy TS! However, proxies are widely available in JS, and you don't need to be using TypeScript to give this a try. I guess you won't get the editor hints for the `find` functions, but everything else will work.
This is how tRPC works. You define functions on the server, and tRPC uses proxies to make it seem like it's available on the client, with type-safety and all, and internally handles serialising the call over HTTP. It's pretty neat.
immer is a fantastic example of Proxy usage
Nice!
Years ago I worked for an employer that was creating metrology lab automation software, and I was responsible for the project since I'm a former calibration tech, metrologist, and dev for 35+ years.
The project was using node-red to allow end-users to create automated calibration procedures that would either ask the user for input during the calibration or directly acquire the data from hardware, perform some checks on or calculations on the data, make a pass/fail decision, and store the result(s).
However, node-red was not 100% up to the task, since there are fundamental parts of the internals that they don't expose. So, I started by forking node-red and customizing it to our liking, but that turned into a maintenance nightmare, and we quickly realized that altering node-reds behavior at runtime was the best approach.
So, I started using Proxies to trap internal node-red calls, altering either the data going in, out, or sometimes both, depending on the needs.
Anyway, thanks for bringing up this somewhat lost part of JS!
Great vid! I love proxies and I use them in Vanilla JS/TS for two-way data binding
Trpc is using proxies... specifically recursice proxies to keep track of all the nested property access you do and convert that to an id that is passed to the trpc router to call the proper method on it. Pretty interesting
wow 😯, that's coool man
we need more videos like this with Ts ofc 😂
Like always, very interesting video and really nice and fun usage of Proxies imo! :)
Vuejs objects are almost all proxies
legend state for react and react native uses proxies
For anything that isn't a getter/setter (maybe getter and setter as well, not sure how that interacts with Object.keys) you can just map over the keys and create the object yourself or am I missing something?
Valtio uses proxies extensively to manage state!
Huh, I've never looked into proxies before but I think I recognise this as what Vue uses to implement reactivity when you change a value in an object?
Yeah, Vue 3 uses it.
VueJS uses proxies!
Everything state related in Vue is a proxy, that's why you do not need to use callbacks for mutation in Vue, you just mutate state directly, render micro task is created automatically
Unless you're developing a library with very tight user experience constraints, I don't think proxies should be touched. It's the worse thing for readability, I've ever interacted with in JS
Proxies are actually a design pattern. It always felt weird to me that the language has a construct that represents a pattern, and feels badly implemented for consuming it honestly. Why JS had to do this? Don't know, but I think implementing the pattern yourself is way cleaner and easy to follow than using the native construct.
Hmm, interesting take! Do you have an example of implementing this manually instead of using the native Proxy?
Thanks for watching & commenting!
@@andrew-burgess I posted a comment that had a TS playground that for some reason got deleted...
@@Guergeiro RUclips marks comments with URLs as spam... :(
@@Guergeiro ah, sorry, I can't control that youtube behaviour. If you still have the link, wanna email it to me? you can find my email on my website, linked in the video description.
I've come across Active Record and Method Missing multiple times in Ruby and Laravel and I've got to say, they're the work of the devil himself.
nice. very clever. another example why AI can ever replace human ingenuity.