I want to start with the namespace feature not to show you how it works.
I will grab these two interfaces here to drag and drop interfaces.
Cut them from apt.
Yes and add a new file drag drop interfaces dot.
Yes for example.
Now we can paste it in there.
And now to use namespace as all we have to do is we have to add the keyword namespace and then curly
braces.
Now we also have to give this namespace a name.
And here are all named DDA interfaces for drag and drop.
The name is up to you though.
Now this year's types could feature not a javascript feature.
It is not compiled to vanilla javascript because there is no direct equivalent for it.
Instead types could will basically compile it to do an object.
You could say to an object where the things you will put into the namespace then are stored on properties
but you won't have to worry about that because all the resolving of access to these properties and that
everything works will be taken care of by typescript.
So now we can move these interfaces into the namespace and with that we're almost done.
Now we have one problem however these interfaces are now only available in this namespace.
By the way you can not just put interfaces into a namespace.
You can put anything in their classes concerns whatever you want whatever you want can be put in a namespace.
So basically you can wrap a namespace around any code you have but the problem we have is that these
features these interfaces here are now only available inside of that namespace.
Now as you see we have nothing else in there.
Now of course we could bring the code that depends on them back into this namespace but then again we
would bloat this because turns out we have quite long clauses.
That depends on these interfaces right.
We have the project list class and the project item class.
They depend on these interfaces so that would be a lot.
We have to add to that namespace data for what you can do is you can add to export keyword in front
of an interface to export a feature from a namespace.
Now what this means is that now these interfaces are a way lable instead of this namespace.
But also I would set off this file and we'll see how this works in a second but with that we make this
interface or whatever we are exporting.
This is not restricted to interfaces of course a way level outside of this file as well.
If we then basically import or use that namespace and of course again you can not just export interfaces
in a namespace but anything.
Now with that the question justice how do we import this namespace now back into apt.
Yes.
And for that typescript has a special syntax you can use.
Let's go back to the top of APT.
Yes.
And now here you add three forward slashes important free not just two because this is actually not
a normal comment.
What we're creating now this will actually be certain text picked up by typescript a Special Comment.
You could say type but understands if it starts with free slashes there you write self closing XOM l
tag so opening angle bracket then forward slash closing angle bracket and in their reference path equals
and then hear the name of the file you want to import.
In my case your drag drop interfaces dot t s.
Now this is understood and picked up by typescript because as I mentioned with the free starting slashes
as a special syntax type good understands just as it understands does reference thing.
This is not vanilla javascript vanilla javascript does not notice and this is not what it will look
like once it is compiled.
Now what does this achieve though this achieves that.
Now this namespace D.D. interfaces is a way lable in Apt yes.
However if you scroll down you see my editor still complains and if we tried to save as we also get
compilation errors so it doesn't seem to be available.
The Dragonball interface doesn't seem to be available here.
Well there is a special thing about name spaces you can use them to split your code.
And remember when I said earlier that what you have in a namespace can be used from anywhere in that
namespace.
Well it turns out you can split namespace across multiple files by exporting things in a namespace and
then using this special import syntax but you then have to put the things that want to use something
from that import namespace or from that imported file into the same namespace.
Hence maybe these interfaces is not the best name.
Maybe we just named as app.
Now if we named as app here we can go to apt yes and create a namespace of the same name here namespace
app.
And now for the moment let's put everything here into that namespace and now you see the error is gone
there are no red dots on the right.
However if I saved it I still get errors here.
For example that finished project list is not used well that is correct.
I am not using that.
I am not needing it either.
So we can simply remove these concerns here with Dad.
If we save this now it compiled without errors the question just is what's the result of this compilation.
Do we have one or two files now.
Well let's have a look at the list folder.
And there you see you've got a aptly as file and then some code here and a drag and drop interface J.S.
file.
So we've got two files as a result.
Now the drag and drop interface file actually is pretty empty because you learned that interfaces are
basically not compile to anything.
There is no javascript equivalent for an interface.
It's a pure type good feature.
So we can't import it with the type could soon tax year to use it and get all the type improvements
we learned.
But in production it doesn't matter if it's in a separate file or not.
So of course the question is What if we now put something.
Dad does exist in production that does exist in JavaScript as well into a separate file for example
does enum and the project class here I'll grab both create a new file project dash model T S and put
my project status enum and project class in there.
Now Justice before we can add a namespace here the name has to be app.
So it has to be done namespace where we then also want to use it and we have to exploit these features
in there so that we can use them in our files in the same namespace.
But in other files as well.
Now back in app yes we have to import that second fall.
So I'll duplicate this import and also import project dash model T S if I save that it now is compiled
and we see a project model JavaScript file and India we see some code.
The question is does our application now work for that.
Let's reloaded.
Let's try adding a project here.
You see we get an error.
Cannot read property active on the find.
The reason for Dad simply is that our files are compiled stand alone namespace as existent types with
the world.
As I said there is no javascript equivalence for it.
So the problem we have here instead and type the world everything is great because typescript is able
to find all the things we need.
For example when I say project here when I reference the project type here on the project state class
this project type this project class is defined in the project model.
Now typescript does not complain during compilation because we import that model but import here really
just means we tell types where to find that type.
Once it is compiled to JavaScript disconnection is basically destroyed.
So in Javascript code when does executes and when we then try to create a new project by instantiating
project.
Javascript doesn't find this project class or a constructor function so we have to make sure we carry
over disconnection.
And for that we can go to the T as config and they are set as our file option.
We can comment this in the idea behind the out file is dead.
You tell typescript that it should concatenate name spaces so these references which it has during compilation
into one single job is good file instead of compiling multiple JavaScript files.
So here for outfall we can say we want to have a file in the dist folder which we named maybe bundle
dot J.S. and if we do that and save that we'll actually get an error here.
We'll get an error that only AMG and system modules are supported alongside outfall.
Now we don't need to understand everything here.
There basically are different ways of loading or bundling different jobs good files into one for historic
reasons and how it is all developed and you can learn more about these different bundle types in an
attached resource if you want to.
You don't need to though.
So basically what we need to do here is we need to set a module which is already highlighted as an error
here not too common J.S. but 2 a.m. D for example if we do that if compiled without issues even though
it still complains here but didn't pick up that I changed it.
And now what happens is actually that there is a new bundle js file in dist.
If I remove all JavaScript files in the disk folder and I restart my TSC dash we process.
So the compiler you see only that until Jess follows generated this file will hold all our code in the
compiled and translated version and they'll for now an index a simple.
We just have to import bundled J.S. here instead of arpeggios and if we do so and we reload here we
have a working application again where we can use drag and drop and everything because now it's all
in one file but only in the final result during development.
We have these namespace is here which is one step in the right direction because it is already is a
bit more manageable.
Now let's split this into even more files before we then have a look at the average splitting option.
Yes modules.