Inyección de dependencias con Backbone

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

so um so yeah so no it's not about Java it's not about abstract factory factory factories this is again pretty simple stuff so it's a very it's a very simple pattern and basically in back own house what it means is that you passing your dependencies

to your constructor objects and then you check for them and you throw errors if they're if they're not present and essentially what this allows you to do is enforce the constraints that are built in inherent to your application so that you know later

on when you're you when you rely on these things that are assigned to you as instance properties like this collection in this example that you know they're going to be there you're creating a contract inside your code that's enforced and it

will throw errors and you know the benefit here is that once the benefit here is that it's easy to test so um thank you for for presenting for presenting on testing earlier this was something I was going to have to kind of pause and explain but up this

is a you know using a jasmine or jasmine or mocha with with try it's very easy to to check thing you know if you try to instantiate this class without a try to instantiate this class without your ok now we're getting back if you try to instantiate

this with without your your actual dependency in there it's going to throw into error you can check that readily and easily and so keep trying to go to that site and it's very easy to understand just from looking at an initialized method what is required

for for a given class instance to to work and to function and so they're going to be showing some more code throughout the throughout the rest of this talk to really show what exactly this means into what the what the benefits are so you're enforcing

your applications restraint constraints by contract and if you're depending on another class just make it explicit that you're doing so throw errors if your dependencies aren't met and pass dependencies as options indeed into your constructors

it's essentially making sure that your application knows how it's going to run and so backbone apps tend to start small and then they get really really large and really really big and so yeah so they get nothing enormous and it can be really frustrating

over time you're working on larger and larger applications that you have classes that you don't know how to use that you don't have a clear pattern for for using and so we're going to be talking about some of the ways to organize things a little

bit better and you know some of the pitfalls that you can that you can run into so the most my favorite line from the backbone documentation and what I tell people when i'm working with teams that are when i'm consulting with them on background apps

is that there's more than one way to do it and so if you've done this differently or if you have different opinions about that that's great one of the benefits of backbone is that it's very flexible and so just keep that in mind so let's

take one step back before before we move in further so backbone apps present two distinct types of organizational problems the first is constructors so constructors are the liberal plans of your application they are they're created to they're made

to create instances and they unless you're assigning static class methods to them they're really not that useful on their own until you actually do something of them until you create an instance so instances this is your application when it's running

this is where the state of your application lips what you especially really care about when you're when you're right when you're debugging you're out when you're actually putting everything together making all these constructors come to

life into an application and so how do you go about organizing these two things well there's the global namespace that you can use very easy to attack things into it creating Global's and javascript is almost too easy to do and you know then there

are module systems that you can use to organize your constructors so um so yeah so I know let's use global variables to organize all of these things and so that what happens is this this is a really common pattern that that most people have used before

and it's can i call it the single namespace blues is that you end up creating these kind of ad hoc standards to what and you have kind of a lot of this boilerplate code of checking that you know if this app exists make sure that all the kind of internal

structure is there before you move on and but then you still have this problem where you're creating you're creating classes and creating naming conventions that don't necessarily have to line up to file names and it's it's also it gets

confusing it eventually your you go to start your app it's fine in this final final snippet you actually go to certain your application and you also have to attach it to the global namespace so that you can access it through the command line perhaps there

we go no pull so the problem is is that this is brittle relying on the global namespace like this its riddle looks like this is one we're trying to get a taco it's just not working and so really outside of the rails out asset pipeline which is based

on based on directives that concatenate that help you concatenate files this is really hard to do in a written it's not very portable when you have to rely on you know a concatenation script to run to slap all your Java scripts together into one bundle

or you're you know dumping a dozens and dozens of script tags into into an HTML document to serve your application even when that's known for programmatically like like it is an asset pipeline it can be it can be brittle it can be unruly and again

this is about ad hoc inventions that you have to that you're that you have to put together to figure out how to do this stuff so lolz go against the grain of modularity dave herman put this really well this is in his book essential javascript effective

javascript other and so Global's also create this committee of this net effect of an intergalactic wormhole your application Global's can change at any given time and relying on their presence either for passing constructors around or passing instances

around is problematic it's a it's something that's that you know is very easy to do and in the simple cases like in to do MVC it's it's shown it's kind of like this only way the lingua franca of like how you do this and its really just

doesn't apply to building large applications and so there's nothing actually like wrong with this there are just more expressive patterns for doing this and so I'm going to talk about modules many people have opinions about modules backbone takes

a stance of kind of finger in the ears neutrality towards modules and that it just attaches itself to the global namespace and then unless you do what you want with it but is common jas compatible and you can shim it with required is so modules can help organize

your constructors so if a backbone app is made up of all of these different instructors that you throw together when you create instances you need to a means of organizing those and tying that into the file system so that you can you know use folders to separate

[ ... ]

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