JSConf 2014

Patrones compartidos de los frameworks Angular, Backbone, Ember, Polymer y React

Marco Rogers  · 




Extracto de la transcripción automática del vídeo realizada por YouTube.

my name is Marco Rogers I work for Yammer and this talk is about as he said finding patterns in front-end JavaScript development so we spend a lot of time talking about JavaScript libraries and frameworks you know which one to choose when to use them when

to write your own which is hopefully never but unfortunately I'm not actually going to give you answers to any of those questions today what I actually can do is give you a peek into the way I think about front-end development today because there was a

point where I realized that there are lots of shared patterns and if we if we look at those shared patterns it'll give us better insights into the landscape of how we build things today so see we can move forward a while back I wrote this on Twitter tweet

sometimes and the question that I got back most I had some people agree but the question that got back most was what are the patterns that you see like people wanted to kind of discuss this which I thought was great so my goal with this talk is to provide

sort of a mental model for pulling out these patterns being able to identify the core concepts and being able to to kind of discuss them across different libraries and frameworks this is gonna be an incomplete list because the stuff is still evolving and and

because I'm I don't know everything unfortunately but I think the best outcome for me is when I get done with this that you're like super annoyed that I didn't get to go further into it and that you want to continue the conversation because

I think that that we need to so let's let's kind of talk about the three main buckets that I put these into the first is common patterns right so this is these are kind of the core patterns that people or at least in my mind the core patterns that

people are referring to when they say NBC or MV star is kind of thing right so we're gonna take a look at one of those and it's gonna be kind of a baseline for how what I mean by via these are these are shared patterns across frameworks I'm gonna

dig into the advanced some of the more advanced abstractions on top of the MVC ish thing this what I think will be interesting for illustrating what I think a lot of us are doing today when we're trying to build complex web apps whether we're using

a cohesive framework like like ember angular or whether we're using our kind of custom-built thing that is about five years old and which nobody really wants to use anymore and yet it's still kind of hanging around I think you see the same patterns

across all these things right and then finally we'll look at some emerging patterns these are ones that are less common but I think are coming up more and more frequently as we try to build apps with with more sophisticated capabilities so let's kind

of jump right in so two common patterns and they they look like this right so models views I want to be pretty obvious I hopefully should be pretty obvious to the folks in this room controllers the sea is always kind of nebulous but I think routers and controllers

are kind of kind of come with that and routing is probably the more important feature for building single page applications right being able to route to a particular view and then like restful api access because obviously you need to get some some data and

shove it shove it into your UI I think these should be pretty familiar to people we're gonna jump into one of them so I can kind of illustrate what I'm talking about so let's talk about models right this will be a rehash for folks and it comes

with these capabilities generally at least this is my contention this is how I kind of outlined this pattern in my head you get some objects that represent your data model right you can expect the properties on that object you can read and write them usually

you can persist data to the server because because that's handy sometimes and then the most important part that I think makes this into a pattern and not just kind of the thing that we do with JavaScript all the time is that this model layer is going to

fire change events it's going to tell you when these models have changed allow you to register a callback so that you can respond right and that allows us to take this model layer decouple it from the other parts of our app whether it be our our views

templates what-have-you but still be able to make it do do interesting things right so does it make sense to people it's not making sense rehash Thanks that's probably good so let's take a look at how backbone does this backbone should be familiar

to most people this looks pretty straightforward you create a new backbone model right give it some data ID this latest reply ad which is kind of a date string you can inspect these properties by pulling out the ID and comparing it to some other things in

anger our backbone wants you to use a getter for this and then you can register a callback right and in backbone it looks like this it uses this nice kind of event listener pattern that was popularized by by jQuery and nodejs depending on who you talk to and

so when latest reply at gets updated this callbacks gonna fire and we can we can do things and then finally we can we can update this model by calling this setter and when we do that then our callback send a fire just this isn't a surprise to anybody right

this is kind of what we do is it's kind of the core of backbone models but let's kind of compare it to what I work with everyday which is you know the the internal framework that Yammer uses which we call y MJS or sometimes affectionately yam juice

and it looks like this I mean let me go back here's backbone our framework looks like this that slide did change they're very similar but it did change and you can kind of see that it's actually doing exactly the exact same thing we're creating

an instance of this destroyed model given it some data we can read the data directly from the property without using a getter because that's how our framework works but it amounts to the same thing then you got this funky-looking hook thing where we're

asking when this thread has an update register a listener right it's not as nice as the the event listener pattern that we we all know and love but it's essentially doing the same it's allowing us to listen for changes and then we want to want

to change this data we have to go through this setter method called update and instead of changing one property we changed multiple at a time by passing a hash and we need to use this setter so that we can get our RF in hooks five time I'll tell you a

story about that what happens when you don't use it so this when I recognize that this looks pretty similar to the other frameworks that I was I was seeing this is when this idea of pattern started to develop in my head because anything that you can do

with this this core concept and backbone you should be able to do with our framework and you should be able to do with other frameworks that say they have a model layer for you right but it doesn't always look this similar and so I wanted to pull up a

different example that looked looked a little bit different so his angular write angular looks different and depending on how you talk to you it's like interesting different or like annoying different but it's different but the outcome is actually

[ ... ]

Nota: se han omitido las otras 3.617 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.