good Monday morning today we are going
to explore the wonders of declarative
programming something that Reax has
managed to popularize in recent years
and the clarity programming is extremely
useful for all kinds of programmers so
don’t turn this video off if you’re not
a web developer and don’t care about
react because there are things to learn
here don’t worry if javascript is not
your thing there’s not going to be a lot
of code in this episode probably not any
at all and I’m not going to assume that
you know anything about react either
with that said let’s get into it
IMM VJ and you are watching Fontbonne
function can you post a comment down
below and tell me your feelings about
react because for me when I first saw
react I really hated it but nowadays for
every year that passes I find myself
liking react more and more and I feel
that I need to know what people in
general feel about RIA because to me the
main big thing would react is that it
allows us to do declarative programming
without the drawbacks that are
traditionally associated with the
clarity programming a lot of people
don’t get the benefit and how huge
declarative programming is and how it
locks in and relates to react I suppose
that this might be because I guess that
declarative programming is a is a bit
different and hard to wrap your head
around but it might also be because
react has these other features that you
get caught up in as a developer and you
develop a strong opinion about them and
you start seeing those features and not
seeing the forest for all the trees so
to speak and I really think that
declarative programming is act with very
core of what react allows us to do so
we’re going to talk about that today
declarative programming and in the
context of react what is react react is
a lie
for building the view of applications it
was initially just for web applications
but over the years people have started
using it for native applications as well
most developers that use react couplet
with a technique called flux it
restricts the data flow of the
application to flow in only one
direction so imagine an application
where you have a view and there’s some
button in that view the button will not
be allowed to change anything in the
view itself or even change any state
itself it will dispatch a click event
and it will end up in this thing the
store which is responsible for doing the
actual manipulation of of the state and
then whenever the state updates the
entire view well rerender based on the
state so this is a unique directional
data flow it only goes near you
actions goes here and state flows here
state change only happens because an
action went this way and if you is only
updated from the state changes it’s a
very simple flow so what’s the benefit
of doing that well it allows us it gives
us a structure for doing declarative
programming and declarative programming
gives us an application that is easier
to reason about and where fewer things
can go wrong when you’re doing the
clarity programming in in the context of
an application like this
you are simply stating that the view
should be a certain way given a certain
state for example you might imagine
given that payment is currently
processing like your press 3 the pay
button the pay button is disabled so
with the clarity programming you are not
quite describing how the applicant
nation should do things you are simply
stating or declaring a relationship if
the concept of mapping makes sense to
you you can think of it that way as well
the opposite of declarative programming
is imperative programming and when we’re
doing an imperative programming we are
telling the computer more directly what
to do we are listening to the payment
events and depending on what that
payment has said we will be setting the
disabled attribute to true or false on
the button the big advantage with the
clarity program is that it’s easier to
reason about imagine that we’re doing
imperative programming and there’s a
payment failure then we need to listen
to that payment failure event and update
button accordingly and explicitly in a
declarative model that code might not
even be necessary in react and flux we
would just have the payment failure
update the state to have the state say
that I am no longer processing a payment
and any existing elements that in the
view that offended on that state will
just update automatically if you have
any experience with declarative
programming please write a comment down
below because first I want to know
because I for me declarative programming
has I feel like it has made me much
better developer I feel that declarative
programming is an extremely nice way of
writing software feels like almost
everything becomes these simple
functions that take state as an input
argument and spit out of view this is
very simple to reason about and there
are very few things that can go wrong
and it’s also extremely easy to test
programmatically declarative programming
is very very nice when you manage to
pull it off but a problem with
declarative programming is run in order
for
to pull it off it needs to redo a lot of
work all the time in the clarity of
programming we look at the state and we
determine what the button in the view
should look like depending on that state
and we are recreate that button from
scratch and throw out the old button we
just throw that one away we don’t even
look at it and this is very expensive
compared to imperative programming which
only does exactly what it needs to do
imperative programming doesn’t destroy
any buttons imperative programming is
very frugal and this is why the clarity
programming was held back at least in in
prompting development because it was
doing so much rear-ending all the time
and you wish you were seeing flickering
and it was hard to get the performance
out of it that we needed and this is
especially true in web development
because of the dome in case you’re not a
web that’d be the Dom the document
object model is how we how we build
interfaces on the web it’s how we
control how things are rendered it’s
pretty heavy performance wise so we want
to touch it as little as possible and
this of course makes declarative
programming problematic because we are
destroying and creating things all the
time and this is where react comes in
with its virtual dome when you’re
building react applications you are
you’re rendering dome but you’re not
rendering real Dom you’re rendering a
virtual Dom which is a version of the
Dom that is much cheaper because it
doesn’t actually render to screen what
reacts then does all every update is to
look at the rendered virtual Dom and
compare it to the actual real DOM and it
automatically figures out the smallest
possible change that it can make to the
real Dom in order to make it mirror the
virtual Dom during the stance would work
Oh Dom it’s not quite as good
performance as doing it manually in the
optimal way but getting there and doing
it optimally and correct manually is
that that is that is harder and unless
you are a very good developer and/or
you’re spending lots of time on it your
implementation might actually end up
being slower and containing more bugs
than the declarative implementation and
in react you can actually fall back to
manual rendering for individual specific
parts of the of the application and I
think that is really really nice when
we’re dealing with abstractions like
this so again using a virtual Dom it
allows us to do with declarative
programming and get the benefits of that
while also at the same time get Chloe
80% of the performance benefits that
imperative programming would normally
give us and there are other examples
beyond react and and front-end
interfaces that are examples of this
this technique or to was that just
imperative programming for an example
that I would like to bring up is
firebase firebase is an observable
database that Google provides and it
allows us to interact with the database
as if the database existed on the client
even though it doesn’t for example you
load a user in in the database and it
goes away automatically and fetches the
the user from the actual real database
on the backend and when you then later
fetch the user again it has actually
cached the user automatically and on the
client so that Ram it’s now
instantaneous it’s kind of sort of like
you don’t have to care that the database
is
on the server you can use and this makes
me app reasonably fast even though you
wrote it in a from a performance
standpoint super naive way so firebase
reminds us of the virtual dome in the
sense that it’s in both cases it’s
optimization that is being automated for
us so in one case it’s the Dom
manipulation that is expensive and that
being automated and in the other if the
network calls to the server and fetching
data that is being optimized for us if
you use firebase and react together you
will experience it it’s a it’s pretty
cool you have our virtual DOM and react
on one end and firebase on the other end
and then you can kind of get away with
just having a bunch of these
transformation functions taking you in
between and yes locks together and even
though it’s super naive it is still
pretty fast because you have your
friends on either side doing the
optimization and I don’t want to
oversell it because it’s not quite as
fast as doing it manually and it will
also be very annoying if you run into
some kind of performance issue that
reactive firebase doesn’t handle well
but in most cases declarative
programming when you are backed by auto
optimizing tools like firebase or or
react it will save you a lot of bugs and
a lot of time I’ll leave you with a
funny thought – in a fantasy world where
we have infinite processing power and a
zero latency and infinite bandwidth we
don’t need to of like react or or
firebase or or observables the same goes
for our X which is a library for
creating complicated observables if we
had infinite performance we would not
need that library we could just replace
the entire rx with just functions that
just do transformations and just have
those functions run all the time so for
the longest time I thought of
observables and as and
architectural pattern which it is but
tools like rx and you know the functions
in the library is like like debounce
for instance that’s not architecture
related that is just related to
optimization and performance that’s
that’s the only reason why we need that
so declarative programming it’s nice
because it is easier to reason about and
there are just fewer things that can go
wrong and react helps us do declarative
programming by reducing one of the big
drawbacks of declarative programming
which is performance and that’s it for
today you have you watched an episode of
fun fun function I believe needs every
Monday morning Oh 800 GMT if you don’t
want to wait until next Monday you can
watch this episode it has been picked
out for you specifically by Lee brain in
a jar that Google brands as machine
learning I am mpj until next Monday morning thank you