The issue with Mermaid link generator has been fixed (and now it also generates shorter links). I posted another comment w/ the link to the PR, but I forget UA-cam auto-blocks those.
I like to call this the "service invoice pattern". You basically compose your code, and at the end, you receive type level information of all the implementations that you need to provide in a flat list, like an invoice
There is actually a good reason for using an Impl class instead of an anonymous instance, and it is debugging a stacktrace, you would rather see GoogleImpl than the weird name anonymous classes get. The default toString is also a nice extra. BTW, I learned that from Gavin in the Typelevel server, so this pattern is also a thing in the `F[_]` world :p
The reason to use final case class for service implementation is that when constructing the layer it is enough to call toLayer extension method. It becomes ‘Service.apply.toLayer’ which is IMO very neat 😊 This also means that ZLayer.fromFunction(make) can be refactored to ‘make.toLayer’
@@DevInsideYou I didn’t know that, thanks for pointing this out. Amazing how quickly knowledge becomes deprecated, I remember watching a talk published on yt in March advertising toLayer
There is a fix for the exit problem with 'sbt'. According to Adam Fraser it has to do with an sbt upgrade. Add it to the project settings: Compile / run / fork := true
Yeah I actually did this here github.com/DevInsideYou/zio-todo/blob/8c3039541df48a4dad55711e6c558f1b036e07a7/build.sbt#L133 but I found it surprising that it is only sometimes necessary. It's not a real fix though, it's more of a workaround. Thanks for reminding me though!
Correct me if I'm wrong but if you would use constructors, you could not share a singleton instance among multiple constructors in such a comfortable way - you would have to manually pass it multiple times.
It's just a convention that I use for the naming of my traits. They describe a boundary (a border) through which outer layers needs to go through to reach the core (the business logic) of my applications.
Ah! Super interesting Circular Dependency issue. The reason is actually because Gate extends Google, so it itself is chosen as the implementation of Google that it needs.
It's just a facade. The purpose is so that I can fake 1 thing when I write tests. It's not visible in the video because in this contrived example I only have 1 thing to begin with so a facade is an overkill. Btw I managed to produce a circular dependency with 1 more facade that I couldn't recover from. I'll show you some other time.
I doubt it. It's not too different from 1.x from a user perspective... "Has" is gone, a couple of methods have been renamed and the layers are composed as I've shown you here.
The issue with Mermaid link generator has been fixed (and now it also generates shorter links). I posted another comment w/ the link to the PR, but I forget UA-cam auto-blocks those.
github.com/zio/zio/pull/6924
Table of Contents:
00:00 Intro
01:15 Demo Walkthrough
06:43 The Service Pattern in ZIO 2
15:35 ZLayer.Debug.tree
16:21 ZLayer.Debug.mermaid
17:17 ZIO.provideSome
20:46 ZIO.servicewithZIO (used to be accessM)
22:19 ZIO.provide circular dependency
27:57 Closing notes
Thanks!
Wow, it's my first super thanks! Thank you!
First ever video that I had to reduce playback speed 😂. Great tutorial, thank you!
I'm really trying to speak more slowly :)
I like to call this the "service invoice pattern". You basically compose your code, and at the end, you receive type level information of all the implementations that you need to provide in a flat list, like an invoice
Thank you so much for this videos!
man, you are awesome, thanks for this kind of video 🙏🏼🙏🏼🤟🏻🔥
Nice demo, Vlad)
There is actually a good reason for using an Impl class instead of an anonymous instance, and it is debugging a stacktrace, you would rather see GoogleImpl than the weird name anonymous classes get. The default toString is also a nice extra.
BTW, I learned that from Gavin in the Typelevel server, so this pattern is also a thing in the `F[_]` world :p
Interesting, I'll have to play with it. Thanks for letting me know!
Agreed, ZIO 1 was awesome but the worst part of its "ergonomics" was layers. Glad ZIO 2 improves on layers and it now works in an intuitive way.
The reason to use final case class for service implementation is that when constructing the layer it is enough to call toLayer extension method. It becomes ‘Service.apply.toLayer’ which is IMO very neat 😊 This also means that ZLayer.fromFunction(make) can be refactored to ‘make.toLayer’
The .toLayer function is deprecated in RC5 github.com/zio/zio/releases/tag/v2. 0.0-RC5
@@DevInsideYou I didn’t know that, thanks for pointing this out. Amazing how quickly knowledge becomes deprecated, I remember watching a talk published on yt in March advertising toLayer
There is a fix for the exit problem with 'sbt'. According to Adam Fraser it has to do with an sbt upgrade. Add it to the project settings:
Compile / run / fork := true
Yeah I actually did this here github.com/DevInsideYou/zio-todo/blob/8c3039541df48a4dad55711e6c558f1b036e07a7/build.sbt#L133 but I found it surprising that it is only sometimes necessary. It's not a real fix though, it's more of a workaround. Thanks for reminding me though!
Correct me if I'm wrong but if you would use constructors, you could not share a singleton instance among multiple constructors in such a comfortable way - you would have to manually pass it multiple times.
Correct.
what is a boundary?
It's just a convention that I use for the naming of my traits. They describe a boundary (a border) through which outer layers needs to go through to reach the core (the business logic) of my applications.
@@DevInsideYou thanks!
You probably need to fork the main process in the sbt setting to prevent it from exiting?
Yeah, it's a workaround though.
Ah! Super interesting Circular Dependency issue. The reason is actually because Gate extends Google, so it itself is chosen as the implementation of Google that it needs.
Could you go into more detail as to why you create a Gate type?
It's just a facade. The purpose is so that I can fake 1 thing when I write tests. It's not visible in the video because in this contrived example I only have 1 thing to begin with so a facade is an overkill. Btw I managed to produce a circular dependency with 1 more facade that I couldn't recover from. I'll show you some other time.
Hey vlad, great video as always!
I'm coming with a request this time. It is for zio-quill(protoquill). Thanks :D
Thanks! It's on my very long "to make videos about" list.
yesss :)
Can you redo the series from scratch for Zio 2 please?
I doubt it. It's not too different from 1.x from a user perspective... "Has" is gone, a couple of methods have been renamed and the layers are composed as I've shown you here.
Makes sense, ty@@DevInsideYou
Well, distage is still better.
I solved the exit bug by specifying "fork := true" in my build.sbt