Very big problems with the design of applications on one page

Question

I am currently writing what will be a very, very large one-page web / javascript application.

The technologies I use are ASP.NET MVC4, jquery, knockout.js and amplify.js.

The problem I encountered is that most, if not all sample applications for one page are for small applications, where all script templates (be it jquery, handlbars, etc.) are all in one file along with the rest of the html code. This is great for small applications, but the application I create is a whole logistic service program with many, many, many screens.

The approach that I have used so far, I have an outer shell (my main index.cshtml file), and I use the jquery load () method to load or rather inject the specific file that I need when the user makes a certain choice .

Example:

function handleLoginClick(){ App.mainContentContainer.delegate('#btnLogin', 'click', function() { App.loadModule('Home/ProductionControlMenu', App.MainMenuView.render()); }); } 

here is the code for the App.loadModule function:

 App.loadModule = function(path, callback){ App.mainContentContainer.load(App.siteRoot + path, callback); }; 

Everything went well until I actually had to interact with various form elements on a recently loaded screen. jquery doesn't seem to be able to deal with them directly. I can not use .live () or .delegate () because they are not events, these are text fields and buttons, and sometimes I need to change their css classes.

They only, what I found is to get the element descriptor from the outer shell (something that was not loaded via .load ()) and use the jquery.find () method as follows:

  App.mainContentContainer.find('#btnLogin').addClass('disabled'); 

it’s clear that I don’t want to do something like this every time I need to interact or even retrieve values ​​from a form element.

Does anyone have any ideas on how I can create a supported very large single-page application with potentially hundreds of .html files without having to have all this HTML in one file and still get around this .load () problem Eat me?

Any thoughts would be much appreciated. :-)

V / r

Chris

UPDATE

I thought I would post the update, as well as how it went and what worked. After much research, I decided to go with the Google AngularJS Javascript framework. This simplified the experiment exponentially, and I would definitely advise anyone looking for a great SPA to look.

References:

The main site is http://angularjs.org/

Amazing free short videos on Angular: http://www.egghead.io/

Answer 1

This is actually a very complex question, as it really fits the design of your architecture.

For large-scale single-page applications, it is best to use some external MV * style structure, such as backbone.js , which is very useful for jQuery. You should also consider using some kind of dependency management framework such as require.js to load your scripts and dependencies asynchronously, or better yet - use the AMD pattern in your application design to make your architecture modular and easy to manage.

As far as this relates to your MVC4 project, you have several options:

• You want to use MVC as a “service level” of types that simply returns JSON objects, allowing your front-end to do markup / template creation (think handlebars.js ) or
• Do you want your MVC project to return partial views (HTML) as an answer, where do you use the Razor template system and just use the external interface to display what is returned from the server?

In any case, you will have to develop a way to handle events and navigation on the front panel (the main chain provides both of these things in combination with jQuery). Even more complex is the template that you want to notify one type of other activities (there are many ways to do this) - for example, a publication / subscription template.

I hope I helped a little, I know that I do not fully answer the question, but the answer can be very long!

Answer 2

There are a lot of things wrong with your approach. I would recommend watching a few presentations about how people build separate pages and what tools are used mainly.

This seems like something reasonable: http://singlepageappbook.com/

At least you want

• some kind of module system (I recommend AMD - http://requirejs.org )
• MV * structure (Backbone, Ember.js, etc.)
• DOM / AJAX Framework (jQuery, Mootools, etc.). Some frameworks offer this and all of the above (Dojo, YUI, Sencha)
• build a solution (have a different environment in development / production)

Some good links:

• http://nerds.airbnb.com/slides-and-video-from-spike-brehms-tech-talk
• http://video.copenhagenjs.dk/video/3413395/simon-hjberg-swipely-building
• http://backstage.soundcloud.com/2012/06/building-the-next-soundcloud/
• http://www.youtube.com/watch?v=vXjVFPosQHw

Answer 3

If you don’t need a complex, truly SOFEA single-page application, I recommend you switch to PJAX .

Then you simply write your application as a regular application for web version 1.0 with the benefits of one page performance. I highly recommend that you consider this option as it allows you to do most of your work with the verification server.

The idea is very simple in every answer when you send the whole page back minus the header and footer (which includes javascript and css). The DOM rendering time is incredibly fast these days ... which is not a complete page reload, so don't worry about the size of the HTML you are returning.

Also the “PJAX way” is much easier to cache , Google SEO is friendly and in fact is the new Basecamp .

Answer 4

Note. This is required to be a comment, not an answer, but not enough to post comments. (
[any corrections of community members are welcome!]

Important points to consider for single page applications:

• Lazy loading is vital since you do not want hundreds of js files to load immediately when the user first loads the pages (very slow loading time).
• Good file organization — Helps facilitate change, slightly reduces complexity, and encourages the use of reusable components. Easier to test components.
• Testing . Since for single-page applications, a lot of javascript happens under the hood, you will need a test environment to automatically test components. This testing is on top of the tests that you will use to confirm whether certain user controls will be displayed, etc., since you do not want the visa-free component to make an ajax call to the server when it should not, etc. d.

+1 for gryzzly specify the use of the framework.

Sencha has a nice MVC framework for its ExtJs product. They have data warehouses, ajax, lazy loading, class hierarchies and much more in the kit. They have a good api page for searching properties and methods of an object (convenient, since there is no intellisense for javascript: /). Their page is api; as far as i know, one page application example. I know most of ExtJs stuff, you can find an open source alternative, but I like that it is only one library, and I do not need to download several different frameworks to perform various operations. [note: I have no attachment to Sencha, except that you are a client and how their material is.]

Output:

I would say that it would be quite difficult to manage a large one-page application without using any client environment; whether it’s open source or not, and without using any architectural template such as client side MVC.

One-page applications, which, in my opinion, are more complex, so your team should be very comfortable in understanding the concept of a one-page application and how to implement it. If you pull it out, the site will be amazing in terms of user experience.

Answer 5

I would recommend using Sammy.js and splitting the different view modes in knockout out into a separate url. And if you use asp.net mvc 4, use partial views (user controls) so that you put all the code in one file. And name everything and separate the entire js code in a meaningful way, the file name and namespace in js. This will help in the long run in maintainability and your own sanity. And use common sense!

Answer 6

The way I did this was to include javascript code associated with the template, along with the template itself. Then download the whole template + script using ajax. If you want to try, you should warn that most browsers do not execute the <script> tags entered on the page. Especially if you do this with innerHTML . Thus, you must eval script tags yourself (alternatively, you can use document.createElement to enter the script, but this does not provide any additional advantages compared to eval, since the browser will blindly execute the script anyway).

In my case, in order to simplify the capture of html and script parts of the template, I save my templates in XML files instead of the usual old HTML. That way I can just use .responseXML to request ajax to parse the template. My template has the following basic structure:

 <template options...> <title>Optional</title> <html><![CDATA[ Template body ]]></html> <init><![CDATA[ // code that only needs to execute once ]]></init> <script><![CDATA[ // code that needs to run every time // the template loads ]]></script> </template> 

You also need to remember how to configure the server to respond with the correct content type for your templates. Otherwise, resultXML will not work. Of course, this is not the only way to implement this system. You can simply save your templates in HTML format and then parse this HTML code to extract scripts to execute.

The bulk of your code, functions, constructors, objects, etc. can be included in the js file. A template script should only call these functions to tell the rest of the page how to work with the template.

If you further separate your data from your template and just fill the template with data on the page or make a separate ajax request for JSON data, then you can configure your server to make your browser cache your templates. This is especially useful for commonly used templates (e.g. dialog box templates). This allows the browser to download the template only once and use the cached version the next time the template is called.

In any case, as I did last time. It scales well enough to serve facebook users (the web app was a facebook app). Just share your experience. Hope this helps.

Answer 7

I have written some great one-page apps using the Dojo Toolkit. I am sure that no matter what kind of JavaScript framework you choose will probably work for you. I use Dojo because it provides me with features that simplify the management of huge single-page applications.

You can use the Dojo widget system to help you define all your screens and forms as widgets, and then when you need them, you can simply instantiate and paste them where you need them. When you want to get rid of it, you can simply call destroy or destroyRecursive on this particular widget, and it is not. The Dojo widget system will also help you separate your HTML from your JavaScript, but still keep it together so that they are not located everywhere.

I have a simple widget definition for a login form.

This is an HTML template.

 /* mine/forms/Login.html */ <div> ${form_name} <label>Username</label> <input data-dojo-type="dijit.form.TextBox" data-dojo-attach-point="_usrfld" /> <br /> <label>Password</label> <input data-dojo-type="dijit.form.TextBox" data-dojo-props="type: 'password'" data-dojo-attach-point="_pwdfld" /> <br /> <input data-dojo-type="dijit.form.Button" data-dojo-props="label: 'Login'" data-dojo-attach-event="onClick:_handleLogin" /> </div> 

This is part of the JavaScript for the widget.

 /* mine/forms/Login.js */ define([ "dojo/_base/declare", "dijit/_Widget", "dijit/_Templated", "dijit/_WidgetsInTemplateMixin", "dijit/form/Button", "dijit/form/TextBox", "dojo/text!./Login.html" ], function( declare, _Widget, _Templated, _WidgetsInTemplateMixin, Button, TextBox, template ) { return declare("mine.forms.Login", [_Widget, _Templated, _WidgetsInTemplateMixin], { // assign the template templateString: template, // signal that we will have widgets within our template and the parser should // locate them and instantiate them widgetsInTemplate: true, form_name: "My Login Form", // place holders that will be referencing the corresponding widgets // that I have placed a data-dojo-attach-point on _usrfld: null, _pwdfld: null, _lgbtn: null, // a call back function that will be trigger when the Login button is clicked _handleLogin: function() { var usr = this._usrfld.get('value'); var pwd = this._pwdfld.get('value'); // now you have the username & password // you can use it to login } }); }); 

There are several advantages that a widget system provides:

• HTML template will be uploaded for you if necessary
• Widgets may have widgets. Dojo takes care of instantiating and even destroying these widgets for you.
• You can use the simple Dojo template language to help with line insertion. The above example uses ${form_name} . If you want to use a more sophisticated object, Dojo also supports a similar Django syntax language. This will allow you to use most of the tags available with Django, e.g. if-then-else, etc.
• data-dojo-attach-point very useful. If you use this, you will no longer need to assign an id to the DOM element. You will not need to search for an element in the HTML DOM tree. The variable that you specify in the data-dojo-attach-point will be automatically assigned to refer to the widget or DOM element that you defined in your template. The above example uses _usrfld , _pwdfld and _lgbtn .
• data-dojo-attach-event also very useful. If you use this, you don’t have to manually add an event hook to the button, the Dojo widget system will hook it for you and also clear the hook when your widget is destroyed.
• If you use a Dojo build system, which is a system that accepts all of your JavaScript codes and compresses them, Dojo will replace your template with actual HTML so that when you load the widget in Dojo mode, you do not need to make another AJAX request to capture your template.

These are just some of the features that I use every day when I develop my projects. Hopefully it will give you some insight into what you can use to make a decision by choosing the appropriate JavaScript framework for your project. As a side note, I am not advocating Dojo or anything else, I just wanted to share what works for me.

Answer 8

To process a large single-page application, it is recommended to split a separate module into different applications.
Example : Applications, such as an application with a search page and a results panel.