Using IBM Tealeaf, require.js, and single page applications - javascript

Can IBM Teamleaf be used on a single page application? Can it also be incorporated with require.js so that it is automatically included once and then picks up all javascript events that are fired?
I haven't used Tealeaf before, but our backend team does, and we're wondering if it is possible to combine it with a single page application that is mainly JS driven using require.js.
If so, should it be included on every single template page, just the main page, in our require.js file, or somewhere else?

The Tealeaf UIC creates a single global variable called TLT which you can easily shim. The API is designed to work with single page applications.

If the TLT object exists on the DOM where your application is loaded (however you got it loaded in there, like with require.js or some other method) you can then use any functionality from the library in your code. You'd probably want to do this where significant events on your front-end occur. Like if you had a React-Redux app with a componentWillUnmount firing at some significant UI action you wanted to track with Tealeaf, you could insert a TLT.flushAll() there to explicitly send a full snapshot to the collector at that instant. If HTML is being dynamically created and destroyed, fire TLT.rebind() after a create or destroy action to tell Tealeaf to re-observe the DOM to account for elements lost or created. I think the TLT API can be found here:
https://www.ibm.com/support/knowledgecenter/TLUIC/UICj2Guide/UIC/UICj2PublicAPIRef/UICaptureJ2PublicAPIReference.html

Related

Vue: multi-page SSR + Hydrate with partial loading

I want to write an application using NestJS. But coming from PHP, I am very much used to the SSR approach of rendering views for the client. Now, by using JavaScript, I could technically ask the server to not completely navigate a page, but just load the <body> element of the sent output, and then embed that into - and overwriting - the current view. By what I can tell, initially, this would work as I would just app.$mount(...) on the initially sent HTML and have Vue hydrate off that.
But what if I want to implement this across multiple pages?
The idea is, that by using SSR, I get to keep basically all SEO related features and can reduce the initially loaded JavaScript by taking advantage of WebPack's lazy-loading feature. But when a user navigates from page A (initially loaded) to page B (subsequent load), I would like to just replace/update the current content and then load the bundle apropriate to that page and hydrate.
Is that possible, and if, how?
So far, I know I would have to unload the currently used bundle to remove all references to events and objects from memory, and then load the new bundle in, which I can then use to hydrate the received view. And this does not take into account that a menu bar might not need to be treated separately, since it will only have to have the current location updated with a .current class appended to the relevant menu item. I might be wrong here, but that is why I ask :)

modify response header without using xpcom in firefox

I am new to extension development. My requirement is to create a simple extension which modifies some response headers and adds some new headers to the http response. I was looking through some addons like redisposition and inline disposition. The former one does the same job without using xpcom and the later one uses xpcom. Also the former one has xul (gui) components too.
Now, is it possible to modify the response if extension has no overlay (gui components).
You don't need a GUI.
There are several ways to get your code running:
Create a bootstrapped (restartless) add-on, just like ReDisposition (The GUI parts there are not required) and register from your bootstrap.js.
Create an SDK add-on and register from your main.js.
Create an XPCOM component and register it for profile-after-change (run at startup, basically) and register once the component gets loaded.
Or have a stub overlay, that will just load a JS code module and register in the module. (A little hackish for my taste, but anyway).
Anyway, in the end, you'll need to register and observe http-examine-response and friends, no matter what method you use, or what
See MDN for more documentation (and the firefox-addon wiki).
Other than that, your question is too broad to tell you something less general.

Very large single page application design problems

I am currently writing whats going to be a very, very large single page web/javascript application.
Technologies I am using are ASP.NET MVC4, jquery, knockout.js and amplify.js.
The problem I am having is that most if not all of the single page application examples are for smaller applications where having all of the script templates (be it jquery, handlbars, etc...) are all in the same file along with the rest of the html code. This is fine for smaller apps but the application I am building is an entire maintenance logistics application with many, many, many screens.
The approach I took so far is I have an outer shell (my main index.cshtml file) and I am using jquery's load() method to load or rather inject the particular file I need when a user makes a certain selection.
example:
function handleLoginClick(){
App.mainContentContainer.delegate('#btnLogin', 'click', function() {
App.loadModule('Home/ProductionControlMenu', App.MainMenuView.render());
});
}
here's the code for the App.loadModule function:
App.loadModule = function(path, callback){
App.mainContentContainer.load(App.siteRoot + path, callback);
};
All was going well until I needed to actually start interacting with the various form elements on the newly loaded screen. jquery can't seem to get a handle on them directly. I can't use .live() or .delegate() because they aren't events, they are textboxes and buttons and sometimes I need to change their css classes.
They only way I found is to get a handle on an element from the outer shell (something that wasn't loaded via .load() ) and use jquery's .find() method like so:
App.mainContentContainer.find('#btnLogin').addClass('disabled');
clearly I don't want to have to do something like this everytime I need to interact with or even retrieve values from a form element.
Does anybody have any ideas as to how I can create a maintainable very large single page application with potentially hundreds of .html files without having to have all that html code located in a single file and still get around this .load() issue I am having?
Any thoughts would be greatly appreciated. :-)
V/R
Chris
UPDATE
I thought I'd post an update and as to how things went and what worked. After much research I decided to go with Google's AngularJS Javascript framework. It simplified the ordeal exponentially and I would definitely, definitely advise all who are looking into making a large SPA to give it a look.
Links:
Main Site
http://angularjs.org/
Awesome free short videos on Angular:
http://www.egghead.io/
This is actually a very complicated question as it really gets down to the design of your architecture.
For large-scale single-page applications, it's best to use some sort of front-end MV* style framework such as backbone.js, which ties in to jQuery quite usefully. You should also think about using some sort of dependency management framework such as require.js in order to load your scripts and dependencies asynchronously, and even better -- use the AMD pattern in your application design to make your architecture modular and easier to manage.
As far as how this relates to your MVC4 project, you have some options:
Do you want to use MVC as a "service layer" of sorts, that simply returns JSON objects, allowing your front-end to do the markup/template creation (think handlebars.js), or
Do you want your MVC project to return partial views (HTML) as a response, where you leverage the Razor templating system and simply use the front end to display what comes back from the server?
Either way, you will have to devise a way to handle front-end events and navigation (backbone provides both of these things when coupled with jQuery). Even more complicated is the pattern you choose to notify one view of another view's activities (there are many ways to do this) -- a publish/subscribe pattern for example.
I hope I have helped a bit, I know I'm not fully answering the question, but the answer could get really long!
Lots of things are wrong with your approach. What I'd recommend is to watch some presentations on how people build Single Page Applications and what tooling is mostly used.
This seems like something reasonable: http://singlepageappbook.com/
You will at least want
some kind of modules system (I recommend AMD – http://requirejs.org)
an MV* framework (Backbone, Ember.js etc.)
DOM/AJAX Framework (jQuery, Mootools etc.). Some frameworks offer this and all of the above (Dojo, YUI, Sencha)
build solution (to have different environment in development / production)
Couple of 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
If you don't need a complicated truly SOFEA Single Page App then I recommend you go the PJAX route.
Then you just write your app as a normal web 1.0 app with the performance benefits of a single page load. I urge you to consider this an option as it allows you to do most of your validation work server side.
The idea is very simple on every response your sending the whole page back minus the header and footer (which contains the javascript and css includes). DOM rendering time is incredible fast these days... whats not is a full page reload, So don't worry about the size of the HTML your returning back.
Also the "PJAX way" is much easier to cache, Google SEO friendly and is in fact what the new Basecamp does.
Note: Wanted this to be a comment not an answer but don't have enough exp to post comments ;(
[any corrections by community members welcome!]
Important points to consider for single page apps:
Lazy loading is vital as you don't want hundreds of js files loaded straight away as user first loads the page (very slow load time).
Good File organisation,- helps making changes easier, reduces complexity a bit and promotes reusable components. Makes testing of components easier.
Testing,- Since single page apps have a lot of javascript going on under the hood you would need a test framework for automatically testing components. This testing is on top of the tests you would use to confirm if certain user controls are rendered etc as you wouldn't want a viewless component making an ajax call to server when it shouldn't etc.
+1 for gryzzly's point about using a framework.
Sencha have a nice MVC like framework for their ExtJs product. They have data stores, ajax, lazy loading, class hierarchies and a lot more all bundled into the package. They have a good api page also to lookup object properties and methods (handy since there doesn't seem to be any intellisense for javascript :/ ). Their api page is; as far as I know, an example of a single page app. I know much of the stuff ExtJs does you can find an open source alternative but I like that it's just the one library and I don't have to download a couple of different frameworks to do various operations. [note: I have no affiliation to Sencha except for being a customer of theirs and like their stuff.]
Conclusion:
I'd say it would be quite difficult to manage a large single page app without using some client side framework; whether open source or not, and without using some architectural pattern like a client side MVC.
Single page apps I think are more complicated so your team would need to be quite handy at understanding the concept of a single page app and how to implement it. If you pull it off the site will be amazing in terms of user experience.
I would recommend to use Sammy.js and split various viewmodels in knockout to a separate url. And if you're using asp.net mvc 4, use partial views (user controls) so that you put all code in one file. And name all and split all js-code in a meaningful way, filename and namespace in js. That will help a lot in maintainability and your own sanity in the long run.
And use common sense!
The way I did it was to include javascript code related to the template along with the template itself. And then load the whole template+script thing using ajax. If you want to try this be warned that most browsers don't execute <script> tags injected into the page. Especially if done using innerHTML. As such you should eval the script tags yourself (alternatively you can use document.createElement to inject the script but this does not offer any additional advantages compared to eval since the browser will blindly execute the script anyway).
In my case, to make it easier to grab the html and script portions of the template I store my templates in XML files instead of plain old HTML. That way I can simply use .responseXML of the ajax request 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 to configure your server to reply with the correct content type for you templates. Otherwise resultXML won't work. This is not the only way to implement this system of course. You could simply save your templates as HTML and then parse that HTML to extract scripts to execute.
The main bulk of your code, the functions, constructors, objects etc. can be included in a js file. The template script only need to call those functions to tell the rest of the page how to work with the template.
If you further separate your data from your template and only populate the template with data on the page or make a separate ajax request for JSON data then you can configure your server to make the browser cache your templates. This is especially useful for often used templates (such as templates for dialog boxes). This allows the browser to download the template only once and use the cached version the next time you call the template.
Anyway, that's how I did it last time. It scaled well enough to serve facebook users (the web app was a facebook app). Just sharing my experience. Hope it helps.
I've written a few huge single page application using Dojo Toolkit. I'm pretty sure whatever JavaScript framework you choose will probably work for you. I use Dojo because it provides me with features that makes huge single page application development easier to manage.
You can use Dojo's widget system to help you define all your screens and forms as widgets and then when you need them you can just instantiate and insert them wherever you need it. When ever you want to get rid of it, you can simply call destroy or destroyRecursive on that particular widget and its gone. Dojo's widget system also help you separate your HTML from your JavaScript, but still keep it together so that they are not located all over the place.
I've include a simple widget definition for a Login form.
This is the 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 the JavaScript portion 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 a few benefits that the widget system provides:
The HTML template will be loaded for you when needed
You can have widgets within widgets. Dojo takes care of instantiating and even destroying those widgets for you
You can use dojo's simple template language to help with inserting strings. The example above uses ${form_name}. If you want to use a more sophisticate facility dojo also supports a Django similar syntax templating language. This will allow you to use most of the tags available with Django like for, if-then-else, etc.
data-dojo-attach-point is very helpful. If you use this, you will never need to assign id to a DOM element anymore. You will not need to locate the element in your HTML DOM tree. The variable you name in data-dojo-attach-point will be auto assign to reference the widget or DOM element you have defined in your template. The example above uses the _usrfld, _pwdfld, and _lgbtn.
data-dojo-attach-event is also very helpful. If you use this, you will not have to manully add an event hook to the button, Dojo's widget system will hook it for you and will also clear the hook when your widget is destroyed.
If you use Dojo's build system, which is a system that takes all your JavaScript codes and compresses them, Dojo will replace your template with the actual HTML so that when you load your widget in production mode, Dojo doesn't have to make another AJAX request to grab your template.
These are just some of the features I use daily when I develop my projects. Hopefully it will provide you with some insight that you can use to make your decision when choosing the proper JavaScript framework for your project. As a side note, I'm not advocating Dojo or anything, just wanted to share what works for me.
To handle large size single page application it's recommended to break the individual module into different apps.
example : apps like search page app and result page app.

structuring javascript in an .net MVC application

I’m looking for some guidance on structuring JS code in an .net MVC application.
I have JavaScript at the bottom of each page which is loaded, I want to apply a name-spacing / modular pattern to my JavaScript, removing it from inline code to separate JS files and load them on demand based on what page is being accessed.
When I google around, I tend to only find MVC patterns for javascript (this for example http://addyosmani.com/largescalejavascript/) which is great but I’m struggling to understand how I can implement this into an MVC application.
Any advice is welcome.
thanks
I use a technique that is similar to the one described here by Paul Irish. However rather than using hardcoded id's or classname's in order to know what scripts need loading and initialising I use the urls that are requested (full requests and ajax reqs)
For instance say I have a customer edit view that is served in response to a request to a url like myapp\customer\12\edit I would have a customer namespace in my js that had an inner edit namespace.
The customer namespace would have an init func likewise the edit. All customer pages when loaded would invoke the customer init event then any action level namespace if it exists. This would have an init func that would be auto called when the page was loaded (I have some magic that parses the url so that we know which js to initialise). So parsing the url would first invoke the customer init fund then the customer.edit init func. There is also common init functions that get fired everytime for app wide logic (to create a sidebar page widget for example).
I do not load the js on demand. I find it is better from a latency point of view to combine+minify all js files and serve them under gzip obviously.

Lazy loading and dependency resolution

some time ago, I was reading an article(a library built by some guy) about how his library can do
lazy loading of JS
resolve dependencies between JS
(typically encountered when trying
to "include" one js from another)
include files only once. thought
specified multiple times regardless
of how they are called (either
directly specifying it as file or
specifying it as one of the
dependencies)
I forgot to bookmark it, what a mistake. Can some one point me to something which can do the above. I know DOJO and YUI library have something like this, but I am looking for something which I can use with jQuery
I am probably looking for one more feature as well.
My site has asp.net user controls
(reusable server side code snippets)
which have some JS. Some of them get
fired right away, when the page is
loading which gives a bad user
experience. Yahoo performance
guidelines specify that JS should
be at the bottom of the page, but
this is not possible in my case as
this would require me to separate the
JS and the corresponding server side
control into different files and
maintenance would be difficult. I
definitely can put a jQuery
document.ready() in my user control
JS to make sure that it fires only
after the DOM has loaded, but I am
looking for a simpler solution.
Is there anyway that I could say "begin executing any JS only after DOM has loaded" in a global way than just writing "document.ready" within every user control ?
Microsoft Research proposed a new tool called DOLOTO. It can take care of rewriting & function splitting and enable the on-demand js loading possible.
From the site..
Doloto is a system that analyzes
application workloads and
automatically performs code splitting
of existing large Web 2.0
applications. After being processed by
Doloto, an application will initially
transfer only the portion of code
necessary for application
initialization. The rest of the
application's code is replaced by
short stubs -- their actual function
code is transferred lazily in the
background or, at the latest,
on-demand on first execution.
OK I guess I found the link
[>10 years ago; now they are all broken]
http://ajaxian.com/archives/usingjs-manage-javascript-dependencies
http://www.jondavis.net/techblog/post/2008/04/Javascript-Introducing-Using-%28js%29.aspx
I also found one more, for folks who are interested in lazy loading/dynamic js dependency resolution
http://jsload.net/
About the lazy-loading scripts thingy, most libraries just adds a <script> element inside the HTML pointing to the JS file to be "included" (assynchronously), while others like DOJO, fetches it's dependencies using a XMLHttpRequest and then eval's its contents, making it work synchronously.
I've used the YUI-Loader that is pretty much simple to use and you don't need the whole library to get it working. There are other libraries that gives you just this specific funcionality, but I think YUI's is the safe choice.
About your last question, I don't think there's something like that. You would have to do it yourself, but it would be similar to using document.ready.
i did in my framework a similar thing:
i created a include_js(file); that include the js file only if it isn't included reading and executing it with a synchronous ajax call.
Simply put that code in top of the page that needs dependencies and you're done!

Categories

Resources