Multiple output files about saltarellecompiler

[erik-kallen]

I'm not too big a fan of this idea, as it can cause all kinds of issues with circular dependencies between classes. Also I must determine how to do it.

I won't close it as a wontfix, but it needs to be reevaluated again after support for the require() API has been added as I forsee major clashes with that feature.

[mattleibow]

Ok, how would you suggest going about having separate files without using many projects?

[erik-kallen]

Don't. Does it hurt? It can actually help performance because all your application pages use the same JS so once it is downloaded, the cached response can be used on all pages.

[erik-kallen]

I imagine though (although I don't know yet) that this feature will be very similar to a feature that could allow code from one import library to specify different module names for require() calls. As I said, I think this will be implemented in the future but I do not want to implement a feature that will cause module loading implementation to be messy.

[mattleibow]

If I am using knockoutjs, i need to only bind once with my vm in the onDocReady. if I have all of them in one file, they would all bind. I suppose I could use Ids, but this doesn't look as neat and I would have to add ids in my view.

[erik-kallen]

I don't understand. I though that the thing that caused Knockout to do it stuff was when you call

ko.applyBindings(model);

Can't you have all the scripts in the same file and apply different models on different pages? Perhaps even adding the call to applyBindings() inside a <script> directly on the HTML page?

[mattleibow]

Oh yes! A face-palm moment :(

I am still relatively new to JS and I never liked it much (that's why I am using Saltarelle :)
But, that was a daft mistake ...

[ashrafsabrym]

I second @mattleibow in this request. This feature is very important.
A large single page application can't usually be packaged in a single file.
It's not just a matter of organization, caching or download speed. But also it may be a matter of security.

For example, the SPA I'm currently working on (and willing to port to Saltarelle), is composed from multiple modules and each module is in a separate file.
The main module loads the other modules when required. Some of these modules are protected by server side authorization.
So, I don't want all my modules in a single file and accessed by unprivileged users.

As for your fears about circular dependencies between classes, you can just add the feature to the compiler and let the responsibility of its usage on the side of developers.
If a developer chose to separate his library into multiple files, it should be his responsibility to reference them in the proper order.

[erik-kallen]

You don't need to package the application in a single file because you don't need to have all your code in a single project. If your project is composed of multiple modules, it makes sense to me to have them in different projects.

As a security advice, hiding the Javascript for certain features is not secure. You should always prevent the things that the Javascript might be doing (eg. action methods), preventing unauthorized people to access the script seems just like security through obscurity to me.

[ashrafsabrym]

Of course having the modules in different projects is an option, but I still didn't make my mind on how to achieve this, as I have some cross references between modules, and I don't like cross references between VS projects.

I do all my security on the server side. The system can't be hacked if just a secured JS module is exposed. But such exposure may give the hacker a starting point to plan to hack the system.

[erik-kallen]

What do you mean with cross references? If you mean normal references between projects, I'm afraid that's something you will need to accept someday anyway.

Anyway, this is likely to be implemented in the future but don't expect it too soon.

[ashrafsabrym]

Currently, in my JS project, I have for example, a Main module referencing a Security module, and the Security module references Main too.
I fear that if I map this to C# I get the same cross references between projects. But still I didn't start working on this yet. Maybe this pattern won't occur in C#.

This issue is not crucial for me. It's acceptable to package the whole project in a single file as far this feature will be implemented one day.

Also, after I pass my current bottle neck, I'll download the project code to start doing something other than complaining about bugs and missing features.

By the way, what the word Saltarelle mean? a music instrument?

[erik-kallen]

We use these kinds of problems with interfaces.
Saltarelle is a song by Camille Saint-Saëns