Sorry, but that is bad advice. all examples in the video trigger runtime error. it must be %StructName{struct | field: new_value} instead, this would cause compilation error on typo.
Great video. Great examples. A minor mistake: 3:00 You said: "or is expecting booleans on both the left and the right hand side and the same is true of and" But that's not true. When the first value is a boolean, the second can be a non boolean. iex(1)> true and 1 1 iex(2)> false or 2 2
Yeah, thanks for mentioning that. I realized that after the recording. Couldn't fix the video without re-recording, but I added a note about that at the bottom of the video notes in Elixir Streams -> www.elixirstreams.com/tips/and-or-vs-&&-comparison
Your videos are amazing! I really had a hard time getting how this worked, but your video perfectly explained this. I've tried and reference the beats project for some navigation, but couldn't figure out how they handled the hooks, now it make sense! I'd love a video showing how to handle pubsub / events via hooks for navbars / notifications. keep up the good work :)
The video is perfect but have one downside if you make PhoneNumber.parse return a result tuple instead of the value will be better sometimes the input is binary but it is a valid phone number
Just started my elixir journey (my day job is kernel stuff) as I found so many similarities between the BEAM VM and some of the scheduling "internals" in Linux Kernels. I'm a decent way through Dave Thomas' Programming Elixir Book (a very good read). Anyway, 01:35 blew my mind. Your short video just did a massive stack unwind on a lot of the "fundamentals" of basic program structure. Man am I glad the RU-vid algorithm brought me here.
I am currently interested in helping modernize a library(snmpex) that has a test for a map order post OTP 26. I wonder if you had this issue after and what are some common fixes for exunit testing for maps that are now unordered.
I hope that it will be possible to separate the type per each function clause and automatically make all function clause's types are combined with an "and". It will be a lot cleaner.
I believe it does (so long as your server can rerender the form data with the phx-auto-recover event). The reconnect logic is really happening on the client side. It just sends the latest changes again on reconnect. So your server (regardless of node) has a chance to rerender the page with the data the client just sent.
Don't know if I love it or hate it lol. If you go overboard, it can look like a ton of nested ternary statements. But for simple functions, this is pretty cool.
😅 I don't think it's "optional" in the sense that we should write Elixir code like that. It's just interesting to know that it's syntactic sugar. And it's helpful if you do any metaprogramming.
Hi German! Thanks for the videos.. Just watched your DDD talk and it was so spot on! And I came here from your Elixir Streams Blog. (Side not, can you add the publishing date of your posts, just to have a sense of when you released them.. E.g. I clicked the video just to see it was posted a day ago!.. Anyway.. Keep up the good work!)
In this example how the main function will return the error paths coming from the helper functions? What I've been using is to put a "main else" in the with statement to do just that.
If we need to add @spec to the main func, the return types would grow into more options. Would it be nice to add just 1 else like 'else -> {:error, "Something is wrong"}' for the main func, so the caller of main func doesn't need to deal with too many possibilities?
Definitely this 👍. Pattern I've settled on is ONLY use function head pattern matching for dispatch logic controlling which function body to use. Any extraction of data from the function arguments should happen in the function body. Also use of defguard/1 and defguardp/1 to communicate the intent of complex guard clauses is useful.
