Leo Dion (host): Welcome to
another episode of empower apps.
I'm your host Leo Dan today.
I'm joined by Brandon Williams.
Brandon, thank you so
much for coming on.
Brandon Williams (guest): Yeah.
Thanks for having me.
Leo Dion (host): I know a lot
of people are fan, fans of your
work point free with Steven.
But I'll let you go ahead and introduce
yourself before we get started.
So
Brandon Williams (guest): Yeah, sure.
Yeah, I'm Brandon.
I do run a site called Point
Free with Stephen Sellis.
It's a video series, educational
video series, kind of concentrating
some of the more complex and advanced
aspects of the Swift language and we
do a lot of open source work we'll
probably be talking about at least
one of the libraries today, but
but yeah that's the general thing.
Leo Dion (host): you've got a big
talk coming up at Swift Toronto
which is going to be awesome, it is
about controlling your dependencies,
not letting them control you.
And now initially when I saw that
I was like, Oh, it's going to be
like about swift package manager,
Cocoa pods or something like that.
But in fact you have a broader
and probably more correct
definition of what a dependency is.
Do you want to explain
exactly what that means?
Brandon Williams (guest): Sure.
Yeah, I think anything you probably
add into your SPM package of course,
you would call that dependency because
you're bringing in someone else's code.
But I think the yeah, the definition
could be a little bit broader.
And it's really just when you have
to touch API's and other people's
code that you can't control.
And so that would even
include Apple's code, right?
You don't ever add a dependency
in SPM to get access to core
location or anything like that.
That's, it's just kind of ambiently
there ready for you, but that still
is a dependency because whenever
you make a direct call to some core
location API, you're touching code
that you can't possibly control.
And that puts you in kind of a
compromised position when it comes to
running your code and certain situations
that you would want to, but it turns
out you can't because you just, you
don't have control over that code.
Leo Dion (host): And I think that's
the key point, is that this is pieces
of your code you have no control over.
So like you, you talk about core
location and how that works.
Anything networking,
obviously, anything database.
Brandon Williams (guest): Yeah
Leo Dion (host): even sleep
timers and that kind of
Brandon Williams (guest): timers,
user defaults it could be it's, and
I'll say even date generators and
UUID generators, all those things
that just can extract out like
new information out of the void.
Like when you ask for a new
date, you get the current
time, all that kind of stuff.
Yeah.
Needs, it can wreak
havoc in a code base.
Leo Dion (host): Yeah, I like, that was
the part that I found interesting is
when you talked about UUIDs and dates.
Because I don't think of those
as you can't control them.
But in a sense, you do get a wild
value every time you call them.
Brandon Williams (guest): Right.
Right.
Yeah.
Every time you do like capital UUID,
open, close, print, that initializer is
you just get a whole new value of it.
And you may not think it's.
that big of a deal to get
a new value out of it.
That is the point of it, but it can
cause trouble for that one in particular
can cause trouble with testing
because you may want to assert that
some model equals some other model.
But if you can't predict the ID that
was generated in the first model,
then you've got No way of comparing
those two as two like models together.
You can't have to compare them
field by field rather, and then
it's on you to remember when you
add a new field, you got to go add
a new assertion for that new field.
Whereas if you just asserted that
this model equals this model, it would
take all of care of all of it for you.
Leo Dion (host): Yeah, so let's
jump into testing, because I
think that's the big thing.
There's two things you mentioned
Xcode previews and testing is
where you run into these issues.
You want to go over some let's start
with the testing part since you
just mentioned that, what are the
particular issues that people will run
into when it comes to testing these
kind of uncontrolled dependencies?
Brandon Williams (guest): Yeah it
just so if you start sprinkling in
code like access to location managers,
network request into your code, you
it becomes very difficult, if not
impossible to unit test and unit
testing is a very particular way
of running your code in which you.
Kind of put it in a little sandboxed
isolated execution environment
where you need to be able to run
it without having spun up a view
controller or spun up a SwiftUI view.
It needs to be just able
to run all on its own.
And if you reach out to a
network request you have no
way of predicting what is the
data that's going to come back.
You know, if you reach out
to some API that loads like
Mastodon posts, you don't know.
what's going to come back.
And so you have no way of then
testing how that data flows
through your application.
And the point of controlling
the dependency so that you can
predict what is coming back.
It's not so that you can exercise what
the Mastodon API is doing where we just
have no choice but really to assume that
they're going to do the right thing.
And they'll send us back some posts.
What we want to test is.
When the post come back, how
does that flow through our logic?
Where does that data get
filtered and transformed and
put into everything else?
That's what we want to test.
And you can't do that unless you in
some way control that dependency.
Leo Dion (host): Yeah, I think
that's one of the biggest challenges
I feel like people get when they
start unit testing is they're like
how do I do this with the database?
How do I do this with the network?
It's no, like you're not testing
that the database works or
the networking call works.
You're testing your behavior
based on what you get back.
Brandon Williams (guest):
Yeah, it's tricky.
I think, and a lot of people
stumble on that when they're first
learning about testing and it
can, I think it can set you back.
If you look at it, you're like, wait.
I don't want to test,
you know, Apple's APIs.
I don't want to test core location.
So why would I do this?
And that's kind of not the, that's
the point is that to not test those
things and to get just to pretend that
their API worked the way you expect
and it fed data into your thing.
But it's very tricky.
Leo Dion (host): So before we
get into solutions what let's
talk about Xcode previews.
What are some things that Xcode previews
like, what are some challenges that
Xcode previews gives you different
from just what unit tests do.
Brandon Williams (guest): Yeah
there are so well, there's a couple
of aspects to this for the first
part, it's the more you compile in a
particular project, the bigger chance
you have of just breaking previews.
And so your first step to Improving
the stability previews is kind of
break up your project into lots
of little modules and that can
greatly improve the stability.
So once you've done that, you've got
a far more stable preview, but then
there are a lot of APIs out there that
will just completely break the preview.
And in a couple of ways first of all,
like things like a core location,
if you just indiscriminately.
Request permissions for location and
you use that check to kind of block
other things happening in your UI, what
will happen is you'll load the preview.
You'll never see that little iOS
alert saying, you know, do you
want to get permission because
previews do not support that.
And I don't know if that's.
considered a bug in previews, or if it's
just how previews are expected to work.
But you'll never get that little
permission box, and therefore you'll
just never be able to see in your
preview what happens afterwards.
And so that just completely ruins that
kind of iterative cycle on previews.
You're just not allowed to use it.
And then there's other kinds of things
that just will completely crash the
preview, because some APIs require
That you have a little info P list in
your application that describes why
it is you want to access that thing.
And that's like anytime you
access the microphone, the
contacts, even the core location.
But for some reason, core location
doesn't do this, but other ones do.
They will just simply crash your
app if you try to access the API
without that info P list being there.
And so then what happens is you've
got your preview and it just crashes.
You just, you literally can't run it.
And that's honestly just the beginning.
Like these dependencies a lot of them
will just make your previews very
flaky, not stable, make them inert and
functionless or just completely crash.
Leo Dion (host): So now we're going to
add it into some like terminology fun
here, but the way I've done it, and
it's kind of what you kind of get at.
And your talk is using mocks, but I
might be using the wrong term because
there's 50 different definitions
of mock stubs and blah, blah, blah.
But that's essentially what I
ended up doing is creating mocks.
And in some cases I'll create a
special mock for previews or a
special mock for unit tests, but
it does whatever you tell it to do
essentially where it's like, Oh here,
in this case, give me this lat long.
Just hard code it essentially, or,
you know, with networking, like
here, give, throw this error in it.
And that seems like basically
what it comes down to as a
solution for this kind of thing.
Is that correct?
Brandon Williams (guest): Yeah.
That's the entire solution is rather
than reaching out directly to like
core location or URL session to
load data, you put a little, a
lightweight interface in front of it.
And then in previews and
tasks, you can swap out.
A implementation to put into your
feature so that it just immediately
returns you some data and I agree.
I don't know whether that's a mock
or a stub or a fake or a spy or
whatever I like that zoo of terms.
It doesn't really matter, because all
that really matters that we have an
interface and at runtime we want to
swap it in with something that does
something a little bit different.
Like when you run in the
simulator on your device, you
want to use the real thing.
You want to use core location.
You want to access those APIs,
but in almost all other cases
you want to put in something.
Just simpler, something just, you say,
give me the current location, and it
just hands you back immediately some
lat long, and then your preview will
hum right along, and it'll be good.
Leo Dion (host): So in your talk,
you talk about protocols is typically
the way I've done it, but you
had some reservations about that.
You want to explain what those are?
Brandon Williams (guest): Yeah alright,
this is like a long, I mean, Steve and
I have been talking about this thing
for many years, and protocols are, yeah,
certainly the most popular, the de facto
way of putting interface in front of
something, but it's not the only way.
There is this slightly different
way in which you can use a struct
that has closure properties.
And I can substitute in for
a protocol for the most part.
And in particular, when it comes to
controlling dependencies protocols, you
typically just got two implementations.
You've got the live one, and then
you got kind of like a mock one.
And in such situations, the protocols
may be a little too high powered,
although Protocols have gotten a lot of
features recently that make this a lot
nicer you know, Rewind Early Swift the
Struct version was a lot more enticing.
Now protocols do satisfy a lot of
things that allow this to be easy.
But anyway, so if you use the Struct
interface, it allows you to do some fun
things, like you get the ability to kind
of hot swap out one single endpoint in
the dependency for new functionality.
So you could.
You could have a mostly live
dependency that accesses the true API
endpoints but you just swap one of
the endpoints to do something with
a mock or something, you know, more
custom and that can be really powerful
for really sculpting very specific
situations that you want to test.
Leo Dion (host): okay.
Interesting.
What were the things that you were
going to mention with protocols that
are new, that make it more enticing?
Brandon Williams (guest): Oh,
just the fact that we have more of
the existential machinery and the
protocol with associated types.
That stuff,
Leo Dion (host): primary
associated types, yada.
Okay.
Brandon Williams (guest): All that
stuff makes it so that it is far
less painful to deal with protocols.
Like prior to swift five, I don't
know if that was six or seven.
It was to me, it was an absolute
no brainer that you would use a
strike for these things afterwards.
I'm just like, whatever suits your
fancy, just, you know, go for it.
But I do think there are pros
to the stroke, the struck style.
But yeah, it's if you're used to the
protocols and go for the protocols.
Leo Dion (host): Yeah, I think I do
protocols probably like 80% of the time
and then the other 20% if I can throw
in a closure and just do it that way.
I'll do that as well.
If it's simple enough, it's just when
I end up having other dependencies
or when I have the protocol needs
to do a little bit more complicated
stuff, it's yeah, I'll probably end
up Do you need to do a protocol?
Brandon Williams (guest): the
more complicated the protocol,
the more it pushes towards like
protocol being the way to go.
But I also say that Apple's, some of
their recent APIs have even skewed
protocols in favor of just simple,
like basically bags of closures.
Like some of their collection view,
like data source stuff, historically
that would have all been protocols.
You would have made your object or
Leo Dion (host): Delegates,
probably delegates,
Brandon Williams (guest): yeah, Delica.
So all that stuff has like slowly
been going more towards Closure Base.
So I mean, it's, yeah there's
nothing all that strange about it,
but they're, yeah, you just got to
think about it a little bit more.
Leo Dion (host): right?
Right.
So one of the other things you
ran into with testing was the
problem with persistence, right?
Especially UI testing where you're
like running, like A series of
tests and something does set
some value, then you run the test
again, but that value had been set.
So now you messed stuff up.
Do you in those cases, I mean, for
me, what I typically do is my UI test
just ends up resetting it every time
it runs, maybe as part of setup or
maybe as part of the test itself.
What do you see as a solution
in that, in those cases?
Brandon Williams (guest):
Yeah, that's, the UI test is
particularly tricky because it
runs in a fully separate process.
So even from the XE test file,
you get no way to do stuff.
You can't clear out.
It's user defaults or
anything like that.
Whatever it does with it, you
know, it happens in a process.
That means you get to add the cleanup
code to your actual application project.
And the way you communicate
between the two is to set like a,
I think an environment variable
or something like that to kind of
communicate to your process that,
all right, I'm running in a UI test.
And then you would set up your
dependencies to use like a fake
file system, something that doesn't
write to the desk, but instead
has a little dictionaries mapping.
URLs to data blobs and then and
the application was like, Hey,
load me some data from this URL.
It'll just give you this data blob.
It won't even touch the
file system or anything.
And so that's the way
you typically do it.
Leo Dion (host): I was going to ask,
going back to the talk about protocols
and you're mentioning file system.
Do you end up having a protocol for
pretty much everything that needs to be?
Like mocked essentially.
So Oh, you are, you never use
URL session, use the protocol
and the protocols implementation
might have URL session.
Is that how you do it?
Brandon Williams (guest): Yeah,
essentially you need an interface in
front of each of your dependencies.
So one, whether it's struct or
protocol, but yeah, interface in
front of your API client, interface in
front of your file system, interface
in front of user defaults database,
core location, all those things.
Leo Dion (host): Do you were you
ever an Objective-C developer?
Brandon Williams (guest): Oh yeah.
Leo Dion (host): Do you miss
swizzling and just being
able to change the classes?
I don't, I'm not that kind of developer
but I can, I see a lot of older, like
Objective-C folks who are just like,
man, I hate how like everything is.
Strong typed and so and that's
like I okay now I see a little bit
of the benefit with Objective-C,
Brandon Williams (guest): Yeah, I
don't really miss it just because
I also remember the terrible
things that when it works great.
But like it injects so much uncertainty
into the rest of your application.
That's really hard to feel comfortable.
And I think other people.
Maybe people are just better
at Objective-C than me.
They just had a higher threshold
for understanding that complex
system all in their head at once,
and I just, I struggled with it.
Leo Dion (host): Yeah.
Yeah.
Yeah.
Brandon Williams (guest): but I think
a lot of this pain around writing these
dependencies, these little interfaces,
a lot of that pain could probably
be mitigated with macros and stuff
Leo Dion (host): Oh Yeah, right.
I figured you're gonna say that.
Brandon Williams (guest): yeah,
so I think we're at least swift as
getting to the point where you will
be able to keep the strong types,
but you'll also have the tools
necessary to put the interfaces in
front of them in a lightweight way.
Leo Dion (host): Yeah.
Yeah Mac I was gonna say macros
is pretty much where that head
that tells you where it's going
was there anything specific you
wanted to mention on testing or
protocols or mocking before I keep?
Keep going further.
Brandon Williams (guest):
yeah all right.
I think one thing I'd like to mention
and is that testing, I just don't think
it's super popular in the iOS community.
I think, if you, I also did a lot
of Ruby back in the day and that
testing and that community is
gigantic and JavaScript's got it.
So and I just I think it's
a little bit unfortunate.
I would kind of encourage people
to just dig in a little bit deep
to see what testing really means.
And this idea of being able to run
your feature in this altered like
execution context is extremely powerful.
All the more you're able to do that.
All it means is your feature is Super
isolatable, super decoupled and can
just be understood all on its own.
And that is incredibly powerful.
And you can only write unit tests
if your feature satisfies that.
And so regardless, I know it's a
lot of people have got like really
hot takes and unpopular opinions on
all these things about testing, I
just, I feel like hopefully just look
through all that fog and kind of.
See what testing can do, because
I think it's incredibly important.
And once you're convinced of that,
I think, yeah, the dependency
stuff is falls out naturally.
You got to do the
dependency controlling.
Leo Dion (host): Yeah.
I agree a hundred percent.
I feel like once you start doing
testing, it's then it's Oh, okay.
Now modularization
makes a lot more sense.
Why do you think, like, why do you think
the community is so testing averse?
Do you think that's a Apple's
fault or tooling fault?
Or is it like, I don't know what
Android is like, but I can imagine it
might be similar with Android as well.
Like just.
Brandon Williams (guest): Java's got
a big testing ethos and history too.
So they do quite a bit of testing also.
I really can't give like a universal
answer why I think it is by some
things that just come to mind are like.
Basically, none of Apple's
sample code has tests.
It's, none of it.
It doesn't matter if they're Fruta, Food
Truck, Scrumding, or all those things.
None of them have tests.
Now, I know Apple does do
testing internally, and I
know it varies team by team.
I know some teams take
it extremely seriously.
But the sample code, I think Apple's
approach with sample code is they
like to build Fun applications in
the absolute simplest way possible so
that anyone can kind of just roll in
and start messing with things that I
think that's their goal with it because
Leo Dion (host): Yeah.
Yeah.
Yeah.
Brandon Williams (guest): They're
making sample code for millions of
people, but that doesn't necessarily
mean you would go and build your
next company, the infrastructure,
you'd build it in exactly the same
way that Apple does their code.
You know, it's a learning tool.
Leo Dion (host): Yeah.
It's a learning tool and it's also
showing off of this particular API
and to, to them, I'm not agreeing
with them, but to them it's oh unit
tests would just distract away from
the fact that we want to show off.
Brandon Williams (guest): Yeah.
And I think it's, I think it's
under, I think it's reasonable.
I, you know, I certainly wouldn't
agree that, you know, people should be
building their applications in the exact
way that the Fruita truck was built,
but I absolutely understand why they
wouldn't add tests and stuff like that.
They really just want to show here are
all of our fancy new APIs this year.
Here's how to use them.
But yeah, I just don't
think we can look at.
Apple is being like kind of the
pinnacle, their sample goes the pinnacle
of how you should build these things.
Leo Dion (host): So you mentioned
I wouldn't want to build a
whole company app around Fruita.
And that kind of brings us to like
scaling and speed because in the
real world we all work in teams
and have to deal with other people.
And we have to deal with speed issues
with, as far as like you said, if you
don't do this, you have to run this
crap in the simulator every single
time, or you can't even run it in the
simulator, you have to run it on a
device, and that just slows things down.
Yeah, you want to kind of expand
on that, I guess, and why those
are big issues with scaling.
Brandon Williams (guest): Yeah, I think
what, just like with modularization can
help kind of paralyze build times and
speed up compiled times, dependencies
can improve developer experience and
iterative cycle on things because
there are a lot of APIs out there
that we already talked about, yeah,
that don't work in previews, but then
there's a lot of APIs out there that
don't even work in the simulator.
If you're making something that
Leo Dion (host): Core Motion.
Brandon Williams (guest): yeah,
core motion, if you're using
something that uses the gyroscope.
That doesn't work in
the simulator at all.
And so you actually have
to run on the device.
Now you may be thinking of
course I have to run the device.
It's a gyroscope.
I want to be able to move my phone
around but that's not all testing you do
sometimes what you want to do is just.
A simulate that the device is being
thrown around all over the place, and
maybe you've got a little graph that's
showing something, like you don't have
to take your device and do this, instead
you could provide a dependency where
Core Motion is pretending like it's
doing that, you can have the little
gyroscope meters going crazy all over
the place, and you know, that would
massively speed up your developer,
the development cycle, you could even
run that in a preview, you wouldn't
even have to run it in a simulator.
And these kinds of benefits just
really start to compound and explode.
There, there is so much that we
do as developers that is just kind
of working around the quirks of
our code base that we've learned.
We've just learned to do it.
It's just, we've been in the mud for
so long that we know that we don't
want to ever clean this project
because it takes so long to rebuild.
We know that we can't ever run this
project, this feature in isolation.
So I have my little flow of.
Open up the simulator and I tap
tap and I get to the feature
and I can finally test it.
All that stuff starts to kind of peel
away when you can just control your
dependencies and allow yourself to start
up your app in the exact state you want.
You don't have to be susceptible
to all of that dependency
corrupt and everything.
You should control all that.
Leo Dion (host): Yeah.
Yeah, I'm sorry.
I was like thinking about Apple
trying to unit test their like crash
detection and how they possibly do that.
Do they like throw the phone
against the wall or what do they do?
Because, yeah, I would hope
that they have some mocking
system for something like that.
Because, yeah, like you said, there's
all these little quirks that you run
into where it's you need the flexibility
of putting something in to replace it.
Brandon Williams (guest): That brings
up, you bring up an interesting point
also is that there's also a bit of
a spectrum with this testing, too,
because you've got the unit tests
at one end where you mock things
because you just want to say, I
assume the outside world is doing
what I expect, but I want, I just want
to test my little nugget of logic.
And then at the other end, you've got
integration testing where you start
to pull in more of the outside world.
And that's extremely important.
It's, I'm not saying that one side
is better than the other there.
You absolutely should be testing along
multiple points of this spectrum.
And like this crash testing they, I
assume they probably do actually have
some little laboratory setup, where
they literally throw phones around.
And that's great, because, you
know, they wanna know, like,
when, at the end of the day,
this thing is working that way.
But then that other thing they
want to test is just that an
alert pops up with this messaging.
I don't think you need to
throw the phone across the
room just to test an alert.
Leo Dion (host): right.
Brandon Williams (guest): would
instead, you would just, you
know, make it fake like it did a
crash and then you see the alert.
So there's like a spectrum
there and you got to test at
every level of the spectrum.
Leo Dion (host): Do you think
one side of the spectrum is
more important than the other?
Brandon Williams (guest): I do not.
Leo Dion (host): Okay.
Brandon Williams (guest): I think
you really need a full around overall
you know, testing on all sides of it.
You really do.
Leo Dion (host): What was I gonna ask?
Brandon Williams (guest): I will
say that certainly the integration
side is the hardest side to test.
And so typically you've got fewer
tests over there because then you
can't really make absolute assertions.
You can't say, oh, I made this network
request and I got this exact thing.
Instead, you can just say, oh, I made
this network request, it fed into my
system and, you know, I can assert
that at least something happened,
but I can't assert that exactly what
happened because you can't predict it.
But.
Yeah, integration testing is
far harder than unit testing.
Leo Dion (host): I think now we can
jump into the muck that is how do
we deal with all these dependencies?
So the way I watch your try swift talk
or new york swift talk, excuse me and
Brandon Williams (guest): right?
Leo Dion (host): No,
you're It was your talk.
Yeah.
In New York.
Brandon Williams (guest):
the one from in April
Leo Dion (host): Yeah.
Sorry.
So I watched that and I was like
my solution is supply default
implementations that are the real thing.
And then in your previews and in your
tests, you're just customize them.
Right.
That's the way I do it.
But you don't like that.
And I liked it.
You had a really good quote that
I say defaults are ergonomic,
but not safe and requirements
are safe, but not ergonomic.
Do you want to explain that?
I guess.
Brandon Williams (guest): Yeah.
So they so yeah, the easiest way to
provide dependencies to your various
features is you have an initial you
hold the dependency as a property and
you know, whatever your thing is a view
controller or observable object and
you provide an initializer that has
a default, which is the live thing.
So the thing that.
makes network request or the thing
that actually accesses core location.
And that way, if you construct
that feature and don't provide
anything, it gets the live dependency
and it all seems really good.
And then over in previews, you
get the opportunity to then.
provide one of those mock things.
All right.
So that can be a really good
way to get your feet wet and
start getting things going.
And it's very ergonomic because it means
you could have some deep leaf feature.
You could be drilled down
multiple levels into your
application and you could be
like, Oh wait, this feature now.
A network client.
So I'm just going to provide
it, provide that default.
Everything compiles.
It's all good.
So that's super ergonomic.
You get to add dependencies
with no trouble whatsoever.
However I call that not being safe
because what it means is say some
other feature up the hierarchy
also wanted a network client.
All right.
If it doesn't pass its network
client down to every feature
along the way so that leaf.
And then you run into the situation
where you could be running a
preview of that parent feature.
The parent feature is using the
mock network client, but that leaf
feature is using the live one.
Because no one passed it all the
way down to the leaf feature.
And so that's why it's unsafe.
That you will accidentally use live
dependencies when you don't expect it.
Unless you're strict with yourself
to pass them explicitly along.
Leo Dion (host): That's what I
mean, that's kind of what I do.
And I would just pass them along.
I would still supply the default, but
I would pass it along, but I understand
where you're coming from completely.
Brandon Williams (guest): Gives
the ergonomics, but it takes away
the safety because then it's on
you to remember to pass along
because the compiler can't help you.
If you don't pass it, it's you
got a default, no big deal.
So that's where the safety bar comes in.
Leo Dion (host): Macro save us, please.
Yeah.
I mean, essentially what you
get I like that solution.
And part of that.
I don't want to have to add another
dependency, which is kind of what
you get at is having to add some
sort of dependency injection library.
And I'm actually in my previous
life we used when I was a.
net developer C sharp, we did
we used what was it was Castle
Windsor, I believe was the
dependency injection tool.
And I thought it was awesome.
Like it was amazing how it worked.
And I wish.
And I think maybe macros actually
might help with this as far as
dependency injection is concerned,
but basically there's a plethora of
library and of course you at point
three, you have one as well that
kind of try to solve this problem.
I don't, I know what dependency
injection is, but I'll let you go ahead
and explain that and then what these
tools actually do and how they're.
that kind of fit the role that
you think is better than the the
way we suggested with defaults.
Brandon Williams (guest): Sure.
Yeah.
All right.
So if you go down the route of finally
controlling your dependencies, and you
provide initializers to pass them in
explicitly, and you find that to be non
ergonomic, so then you throw in some
defaults, and then you find that to
be not safe, The only point of adding
a library to this entire system is to
find a balance between something that is
pretty ergonomic and also pretty safe.
You'll never have the fullness of
ergonomics and safety at the same time.
There
Leo Dion (host): It's a compromise.
Brandon Williams (guest): Yeah
but initializers that don't
have defaults are extremely
safe, not ergonomic at all.
And then initializers with defaults are
extremely ergonomic, not safe at all.
So you're trying to find
somewhere in between those two.
And that's the only purpose of a
dependency injection framework is
allow you to provide The network client
and the core location client to the
feature that wants it in a way that's
slightly ergonomic and slightly safe.
And where you draw the line
there is like up to the library.
And so we've got our own library.
There's probably a dozen or more
other libraries in the Iowa community.
And we, yeah, we try to strike our
balance between those two things.
Leo Dion (host): The idea being is
you can say you know, use this type
and then you tell the dependency
injection, use this type essentially.
And then basically a singleton, you
kind of resolve it and then it gives
you the type that you had already set.
Is that right?
Brandon Williams (guest): Yeah,
essentially you'll have some kind
of way of annotating in your feature
like a view controller observable
object saying this object wants
a dependency of this type and it
will be the job of the dependency
injection library to figure out where
does it get that thing concurrency.
Pretty much the only way to do this
would have been you do have this
global Singleton of dependencies and
you get to pick from it and provide
it to to features, but then there
would be additional Functionality.
Maybe you can scope that global
singleton to something smaller so that
this set of features gets a little
bit slightly different dependencies.
There's there's other things you
can do and there's something called
containers and stuff like that you
can really dive into if you want.
But post Swift Concurrency, there's
now something called Task Locals.
And Task Locals allow you to
have something that looks...
global, but it's actually quite safe.
It can be thread safe or it is
thread safe and it plays nicely
with structured concurrency.
And so that's the tool we use
to build our dependency library.
All of dependencies are
basically held in a task local.
Leo Dion (host): I mean to me like the
drawback with that is, For one thing,
do you ever see Apple coming in or?
I'm just saying here's a
dependency injection way to do
things using macros or whatever.
Do you think that could ever happen?
Or do you think that we're pretty
much going to have to bring in
third party libraries to do this?
Brandon Williams (guest): I think
it could theoretically happen.
It would be surprising only for
the fact that Apple has never once
shown any interest whatsoever in The
idea of controlling dependencies.
They do not even build APIs that are.
control friendly.
Like, all right, for example, the
standard library has some, like,
all right so when Swift concurrency
first came out, we had task.
sleep, and that was a way to
sleep an async context for some
amount of time, but that is a
completely uncontrolled dependency.
If you sprinkle that into your
code and then try to test that
code, Your test will just literally
have to wait for time to pass.
So if you needed to wait 10 seconds
before something happened in your
feature, like confetti or something,
you would just, your test would
have to just wait 10 seconds.
So then in the next, like in a update
to Swift concurrency, they released the
clock protocol, which is an abstraction
and interface in front of sleeping.
And then that allows you
to substitute in clocks.
You get to use a continuous
clock when run on a device,
but you could use an immediate
clock or a test clock and test.
So that is one of the only examples
I can think of Apple providing
interfaces that actually make testing
easier, like all their other APIs
core location, core, locate, motion,
context, framework, all of those,
you just get types, you don't get
interfaces in front of those types.
Leo Dion (host): Right.
Right.
Brandon Williams (guest):
it would be surprising to me
if Apple came out with some.
You know, wonderful way of
doing dependency management.
Now, however, I'll say SwiftUI is.
From its very foundation,
a gigantic dependency
management system, essentially.
Like environment variables
and environment objects.
That is all about how do you
take something and push it
deep into a view hierarchy.
So we've got the tool at the view
layer but I think that was probably
out of just pure necessity of wanting
the idea of if you set a foreground
color on this view, the fact that
it needs to be able to trickle deep
into the view hierarchy, I think
That, that drove that nec necessity.
It wasn't that they were like,
oh, we've got dependency clients.
We need to control, therefore
we need the environment value.
I don't think that was their line of
Leo Dion (host): Right.
Right.
Brandon Williams (guest): and so
what our dependency library, what we
take inspiration from the environment
values and we try to give a tool
that looks like environment values,
but you can use it in observable
objects and stuff like that.
Leo Dion (host): I was wondering if that
was like a limitation of Objective-C and
they're like, yeah, we're not going to
do because we can do a bunch of other
stuff we had talked about previously.
But then I'm like, yeah, all
these new Swift APIs are all.
said not protocols or interfaces.
They're just types like Swift data.
It's all strongly typed So yeah, okay.
Yeah.
Yeah
Brandon Williams (guest): Yeah I
can definitely buy the argument
that Apple didn't really ever see
a need for dependency management
control and stuff like that.
And Objective-C day, because
everything was so loosey goosey with
message dispatch and stuff like that.
I just, I don't know what
their plan is for swift.
I don't know how people
within, you know, app like the
people building the weather
Leo Dion (host): Have you ever
looked at any of the open source
stuff and seen how they do it?
Like
Brandon Williams (guest):
what open stuff do they
Leo Dion (host): I don't know like
foundation or collections or algorithms
Brandon Williams (guest): those are
like foundational libraries that
don't benefit from this kind of thing.
It
Leo Dion (host): Yeah, right,
Brandon Williams (guest): If they
ever open source the weather app,
I'd be very curious how they deal
with things in the weather app.
You know, something like that.
Leo Dion (host): right, right.
Yeah, I think we
covered most everything.
I do, was there anything
else you want to talk about
before we jump into WW at all?
Brandon Williams (guest): No.
I mean, maybe something
will come up, but
Leo Dion (host): Yeah.
Brandon Williams (guest):
to mind right now.
Leo Dion (host): So I was going
to ask more focused on WWDC
has any of let's start with the
Swift UI and observation stuff.
Has that changed any of your
views as far as how dependencies
should be managed or is it pretty
much, Oh yeah, it's all the same.
Cause there was a lot of stuff, you
know, with like property wrappers
that essentially are kind of like.
Not needed anymore
because of observation.
Has that changed any of your views
on dependency management when
it comes to especially Swift UI?
Brandon Williams (guest): It
has not changed any of the core
views of dependencies, but the
observation tracking stuff does
open up a new possibility, new
powers we could possibly give a
dependency library like our library
or anyone can add to the library.
So one of the things that we do
with our dependency library is that.
If you start using it in your feature
and then you write a unit test for
that feature and you don't override
the dependency in the test, you
get a test failure the moment your
feature even accesses the dependency.
So if you got like a
method that says the.
You know, load data button
tapped and inside there, you
go into your network client.
You're like, oh, load data that
will trigger a test failure because
the opinion of our library is that
if you accidentally use a live
dependency in a test, that is most
likely not the thing you want to do.
And so we complain really loudly
saying you're using a live dependency.
You probably don't mean this.
If you do mean this, you can be
explicitly say, I do mean this, but
Leo Dion (host): Right.
Right.
Brandon Williams (guest): right?
And so then there's so we force you
to override that dependency and we
have a tool that allows you to write
your test where you get to override
the dependency, but there's a flip
side to that where if you then you
construct your model in the test and
you override all its dependencies,
but say you override too many
dependencies, there is the idea
that maybe that should be a failure.
If you override dependency that
wasn't actually used, yeah.
Maybe that should be a failure
because then you get to trim
down the dependencies you
override to the bare minimum.
And that really allows you to prove that
you know how this feature is working.
And that kind of, being able to have
that insight of what features are being,
what dependency endpoints are being
used and which ones are not being used.
I think all the observation
tracking will help with that.
And that's a completely non
SwiftUI application of that tool.
Just the idea of the observation
in general I think will be.
Really, and it's just going to allow us
to build some very interesting tools.
But the idea of controlling
dependencies, observation alone,
doesn't really change that story.
Leo Dion (host): Right, right.
How about as far as like using macros?
Brandon Williams (guest): Macros
just will make, finally, controlling
your dependencies more ergonomic.
It may be using our library more
ergonomic, but, yeah, it doesn't
change the reason to do it or
Leo Dion (host): Right, right.
But now you have syntactic
sugar to spread around to
make it a lot easier to do.
Yeah.
Brandon Williams (guest): The, for
example, like registering a dependency
within the library so that you
can start using in your features.
It is a multi step process, just like
with environment values, you have to
create this like little environment.
For SwiftUI environment values, you
create an environment key, you conform
it to a protocol, you extend environment
values, you add a computed property.
Leo Dion (host): Right, right.
Brandon Williams (guest): all of
that could be macrofied and, you
know, a one stop kind of thing,
Leo Dion (host): Have you jumped
into creating your own macros yet?
Brandon Williams (guest): Yeah, we've
experimented with it quite a bit.
Mostly for our KSPAS library
and composable architecture
and stuff like that.
Yeah.
Leo Dion (host): Pretty easy,
comfortable getting into swim
syntax and stuff, or what?
Brandon Williams (guest):
Swift Syntax is a beast.
It's it's
Leo Dion (host): know it is.
Brandon Williams (guest): yeah.
And you really need autocomplete to
help you out every step of the way.
Cause that is, yeah,
there's so much there.
There's like this AST, Swift Syntax
Explorer website that allows you just to
paste in some Swift code and it prints
out the Swift syntax code alongside it.
So you can kind of just see what every
little thing corresponds to and that
Leo Dion (host): Yeah.
Yeah.
Brandon Williams (guest):
what the heck is going on.
But yeah, it's Swift Syntax is a beast.
Leo Dion (host): I'm glad you said that.
Not chat GPT.
That's good.
Brandon Williams (guest): Yeah.
Leo Dion (host): And then last but not
least with data, where do you see that
fits in as far as dependency management
is concerned and mocking that?
I mean, I guess you've already
had stuff with core data, which
of course is a dependency as well.
That's certainly a wild card.
Is it kind of the same
way with Swift data?
Brandon Williams (guest): So what?
Yeah, it's basically the same story.
I think so.
So it's really just to enter like
a nicer API on top of core data
Leo Dion (host): Oh yeah, exactly.
Yeah.
Yeah.
Brandon Williams (guest): I
think that story is the same.
But what?
Sorry.
So one thing that's interesting
about core data, and I think I
misspoke a little earlier when
I was like, I'm trying to think
of examples where Apple is made.
APIs that are control friendly
or testable friendly core data
actually does have a little
bit of that because it has the
concept of the in memory store.
You know, usually when you're running
in the simulator on device, you're
Leo Dion (host): it writes
it to a SQLite file.
Yeah.
Brandon Williams (guest): and
there is the option where you get
to say, all right I want to load
up my application and I don't want
to use that sequel light file.
I just want to say I want
it all to be in memory.
That way, when the application is
killed, no data was persisted and that
can be incredibly helpful for you.
I test and unit tests
and stuff like that.
So that's a really good tool, but
That's the same story, regardless
of Swift data or core data that's
just kind of been carried over.
So Swift data, I, to me, I don't
know of anything special about
it that changes dependencies.
I mean, the most special
thing about it is just.
of how it plays nicely with SwiftUI,
like when, because you know,
historically, if you threw a reference
type into a SwiftUI view just in the
most naive way, none of its changes
would cause updates to the view.
And now we've got the machinery that
allows you to throw in a reference type,
and you make a mutation to something,
and it does update the SwiftUI view.
So that is big, and I think
that will be highly applicable.
Outside of Swift data
and observable objects.
I think you will be able to you could
have the idea of a, at one of our at
dependency property wrappers could
potentially hook into that so that
you could actually use it in the view.
Whereas typically right now you use it
in the observable object or the view
controller, but there are other places
I think you could start using it.
Yeah.
Leo Dion (host): Anything else you
want to mention before we close out?
Any sneak previews of
new point free stuff?
Brandon Williams (guest):
Yeah, I mean, let's see today.
So next week we're releasing 1.
0 of the composable architecture.
It's been in development for four years.
And so that's a big release.
And yeah, all the observation
and macro stuff, it really
fundamentally changes so much of what.
We've always wanted to do with
the composable architecture and
what wasn't really possible.
And so there's a lot of big stuff there.
And yeah, we've got this Swift
dependencies library just github.
com slash pointfreeco
slash swift dependencies.
And it's, and there, and we've got
links in the readme to all the other
dependency libraries out there.
Cause I am in no way saying
people should go and use ours.
Like we, we have made some very
particular decisions in the
design of our library that.
Makes it so that we can't even
do some of the things that
the other libraries can do.
But then, on the flip side, is that we
can do some things that they can't do.
It's just, there's tradeoffs
all over the place.
And I highly recommend people
go look at those libraries.
But yeah, we've got our
own version of the library.
And yeah.
I encourage people to check it out.
Leo Dion (host): Brandon, thank
you so much for coming on.
It was great to have you.
Where can people find you online?
Brandon Williams (guest): Yeah it's
MbrandenW on Twitter and then also on
Mastodon on the Hackaderm instance.
Leo Dion (host): Yeah.
Yeah.
Awesome.
And then of course, point free
we'll have links to that as well.
People can find me on
Twitter at Leo G Dion.
My company is bright digit.
If you're watching this on
YouTube, please and subscribe.
If you're listening to
this, please post a review.
Thank you so much for joining us.
And I look forward to
talking to everyone again.
Bye everyone.
Brandon Williams (guest): Thanks.
Bye.
