v3.0.19 - April 16, 2014

As a part of our ongoing efforts to make JS SDK better we decided to conduct SDK components performance audit. We completed a first iteration of the audit and the main highlight of this release is the set of changes performed as a result of the audit. We started with the memory consumption analysis and found a few issues which affect user experience:

• the main one is incorrect Stream item data deallocation after its destruction. For example if an item was removed from the Stream, some references to an item data (specifically to a target DOM element) were still kept which prevented data garbage-collection by the browser. We updated the code to destroy an item properly which helped us to avoid memory leaks.
• we also updated Echo.Event library to consume less memory. Since this component is widely used across many apps and plugins, this update should help a lot.

In addition to performance improvements, this release contains some modifications of the base Echo.Control class. We added a new config parameter called refreshOnUserInvalidate, which provides an ability to control an app behavior on user login/logout. Previously if a user logs in/out an app was rebuilt from scratch to reflect that. However we faced a few cases where a complete app rebuilding is unnecessary and even harmful. In order to provide maximum flexibility and leverage complete re-rendering where appropriate, we kept the original logic but now you can control if you want Echo.Control basic functionality to take care of an app refresh or if you want to manage it within an app yourself.

v3.0.18 - April 8, 2014

This release contains a fix for the Echo Loader library which is responsible for dependency management and resource loading across all Echo JS SDK based applications. Sometimes it failed to load dependencies in Firefox and Internet Explorer browsers properly. It was caused by a bug in the Yepnope library which is used internally for Echo Loader. The library is now patched and covered with tests.

v3.0.17 - February 27, 2014

• Canvas config loading machinery was updated to avoid race conditions when a browser tries to retrieve config which was cached by a browser previously. We updated the logic to make sure that an execution order always remains the same.
• WebSockets connection reestablishment logic was improved to be more fault tolerant to socket connection closing delays. Previously it caused a delay (up to a few minutes) to switchover to Polling method. Now if the socket is not closed within 10 seconds, we drop the connection and switch to Polling immediately to avoid any delays in live update items appearance.

v3.0.16 - January 14, 2014

• StreamServer live updates connection logic was updated and now if WebSockets are enabled, we try to establish a connection using WS first and fall back to Polling if our attempt failed or timed out (within 5 seconds). Previously both Polling and WebSockets were initialized in parallel and Polling got disabled when WS connection is established. This new connection logic is more efficient from both server-side and client-side standpoints.
• StreamServer live update errors received via WebSockets connection were displayed within a Stream UI (instead of the Stream items). The logic was updated to avoid live update errors rendering in the main UI.
• While making "POST" requests via Echo.API machinery in IE, a timeout handler was initialized in an incorrect place. As a result, an error callback was still fired even though a request was completed successfully. This problem was resolved to avoid error callbacks from being executed after successful operation completion. The most visible manifestation of this issue was an error popup displayed after successful item submission via a Submit form.

v3.0.15 - November 18, 2013

• After switching the Canvas data extraction from CORS-based to JSONP-like method via YepNope library (which we use to load dependencies) in v3.0.14 release, we faced the problem that in some cases the Canvas data cached in the browser (along with the JSONP-wrapper code) became unavailable due to the specific way the YepNope handles it. So we decided to utilize $.ajax jQuery function with the “script” transport behavior to retrieve the data from the Canvas config storage to make sure that the cached resources are still available in JS code. This is an internal machinery update, so there are no performance or any other implications for the publishers and end users. We will switch back to the CORS approach as soon as it's fully supported by the Canvas config storage.
• We’ve slightly updated the Stream app logic which handles live updates. Under certain conditions (for example when a root item arrives with a child node while the stream is paused), the child nodes might not be displayed in the stream. The problem is now resolved so no items are dropped.
• The machinery which takes care of switching to Polling method in case a WebSockets connection is closed (either proactively by the server side or in case of connection problems) was updated to avoid massive simultaneous connections. Now when the SDK machinery detects that the WebSocket connection is closed - switching to Polling is taking place with a slight delay, random for all users (in a 5-15 seconds range). When switching to Polling, the SDK retrieves items starting from the WebSockets disconnect time, so no live updates are dropped while changing transport.

v3.0.14 - October 28, 2013

• In order to improve security, we performed some updates to enable HTTPS protocol for the endpoints which manipulate the Backplane channel ID, specifically:

  • requests to “users/whoami” to get the user data;
  • all submit operations via Echo Submission Proxy (including “Likes”, “Flags” operations as well as posting new items via Submit form);
  • user logout request;
  • Backplane channel requests.

  It basically means that the mentioned endpoints will be requested using secure connection irrespective to the current page protocol.

• We discovered the situation where an App with no Backplane configuration affected the user state (switched it to anonymous state) and as a result the state was not updated even though other Apps had the Backplane information available. We made the logic more tolerant to that situation and we re-initialize the user in case the Backplane information became available on the page.

• We made the "transport" configuration parameter value consistent across the whole API-related machinery. Now it’s called "websockets" in all places. We renamed the corresponding Echo API transport class to WebSockets as well. Please make sure that the “websockets” (not “websocket”) value is used in your configs.

• The missing docs for the "onUpdate" and "onError" events of the Echo Counter App were added.

• We fixed the missing new item animation in the Stream App. The problem was caused by the missing backwards compatibility for the liveUpdates.timeout configuration parameter for the Stream, FacePile and Counter applications. The backwards compatibility was restored, however please note that this parameter is deprecated and should be replaced with liveUpdates.polling.timeout parameter.

• The "More" button was sometimes visible in the Stream App even if there were no more items to display. The issue is now resolved.

• Because of the issue with cross-domain AJAX requests to get Canvas configs from the third-party vendor storage (in case the Canvas is requested from multiple domains), we switched the way we extract the Canvas data to JSONP-like one to ensure the consistent behavior across all supported browsers. This is an internal machinery update, so there are no performance or any other implications for the publishers and end users. We will switch back to the AJAX (CORS) method as soon as it's fully supported.

• WebSockets re-subscribing logic in case of subscription termination signal sent from the server side was updated. Previously we sent the “since” parameter along with the search query to re-initialize the view in StreamServer, but the view was not registered, because of the “since” parameter (which indicates that this is a live updates request). As a result, no new live updates reached the client side. The problem is now resolved. We have updated the code to prevent the “since” parameter from being sent while re-initializing the view.

v3.0.13 - September 30, 2013

• We have updated the Echo.Loader.initApplication function and added the delayed initialization support for apps. This mode was originally implemented for the Canvases machinery only (in v3.0.11) and now we are extending the support to include the apps initialized via Echo.Loader.initApplication function. This new loading mode allows to delay the app loading until the app target becomes visible in the user's browser. This option is disabled by default. In order to enable this loading mode you should specify the "init" parameter in the config object passed to the Echo.Loader.initApplication function. More information about this mode can be found in our Documentation center here.
• In order to make the client-side scripts caching more effective, we've updated the Echo.Loader machinery to load JS SDK scripts from the latest stable version (for example, "v3.0.12") vs current ("v3") version. We've also updated the response headers for the resources served from our CDN to instruct browsers to cache stable location resources for a longer period of time, like 2-3 months vs 24 hours as defined right now. We believe that it should improve the client side performance by avoiding unnecessary requests to download resources (like scripts, images, CSS files, etc) from the CDN.
• The logic of the user initialization in Echo.App and Echo.Control was updated to provide an ability to override the "whoami" and "logout" URLs. This ability was added to provide the configuration flexibility in case the code should work with different (non-default) StreamServer cluster. The "whoami" and "logout" URLs are generated using the "apiBaseURL" and "submissionProxyURL" config parameters and passed into the Echo.UserSession. So, to override these URLs you can pass only "apiBaseURL" and "submissionProxyURL" into an App constructor.
• Another update related to the user initialization was performed in the Echo.Canvas class (responsible for the Canvas initialization). Due to the fact that apps inside the Canvas might not necessarily use Echo users machinery, we decided to avoid the user object from being initialized inside the Canvas. Thus, we removed the "data-canvas-appkey" attribute from the Canvas DOM element container. Also the "data-canvas-appkey" parameter was a bit confusing in a context of the Canvases, making the AppServer and StreamServer tightly coupled. Since the appkey parameter is now removed, the Canvases machinery becomes StreamServer-independent.
• The JS exception was thrown in case of sending a request using the "POST" method and the "JSONP" transport. We have fixed the issue in the Echo.API.Request class and prevent the JS exception from being thrown.
• We have changed the default behavior of the Canvas loader machinery. Now the loader is fetching the Canvas data from production storage by default. Previously the development location was a default one and you had to instruct the loader to use the production location when you go into production. Now it's the reverse: if you want to work with the Canvas in development mode, you can specify it using the ' data-canvas-mode="dev" ' HTML attribute in the Canvas
  container or by switching the SDK engine to debug mode for your session by adding the "#!echo.debug:true" into the anchor part of the page URL as described here.
• Another important Canvas loader machinery update: we provided the ability to load the same Canvas data from multiple domains using CORS (cross-domain AJAX calls). Previously there was a limitation that allowed Canvas config to be loaded from a single domain only. This limitation was removed and now you can place the same Canvas on different domains (for example: dev, qa, prod).
• We have updated the Echo.API.Request class and added extra validation for the "transport" key. Now if the "transport" key is defined incorrectly, this value is ignored.

v3.0.12 - September 18, 2013

This release is completely devoted to the WebSockets support implementation in the JS SDK transport layer. This will make live updates instant for client apps. This technology is relatively new, but it's already supported in ~73% browsers (and growing fast).

For now, WebSockets support is disabled by default so there should be no noticeable changes to your app unless the feature is explicitly turned on.

Currently WebSockets support is implemented for "search" API updates only via the new "ws" API endpoint.

You can enable the new transport for the Stream and FacePile apps. In order to enable WebSockets support, please include the "liveUpdates" object in the app config.

Example:

   new Echo.StreamServer.Controls.Stream({
       ...
       "liveUpdates": {"transport": "websockets"},
       ...
   });

In the case where Websockets is not supported by the client browser, the SDK will revert to the current Short Polling mechanism.

Important: we are releasing the WebSockets support in test mode, so please contact us at [email protected] before enabling it for heavy-traffic production sites. We will perform capacity planning if needed and will monitor the server side behavior to make sure that you get the best experience and performance.

v3.0.11 - September 10, 2013

• We introduced a new Canvas loading mode within the Echo.Loader class. This new mode allows to delay the Canvas apps loading until the Canvas target becomes visible in the user's browser. We encourage you to use this feature to gain better performance in case you have widgets located below the main content area viewport when the user opens a page (for example, comments widget underneath the article).
  In order to enable this new loading mode you should specify the "data-canvas-init" Canvas target attribute as "when-visible". The default behavior (if no additional parameter is specified) remains the same: the Canvas is being initialized on the page as soon as is's found by the Echo.Loader after the Echo.Loader.init function call.
• We have updated a few HTTP headers (including "Cache-Control", "Expires" and "Content-Type") returned by Echo CDN while serving scripts to the client side. Having the updated headers in place allows to make the browser caching more efficient, predictable and consistent, to avoid the same resource downloading multiple times. This update contributes to the performance improvements performed within this release.
• We have fixed the issue in the YepNope third-party loader library, employed by JS SDK to download JS and CSS dependencies for apps. In some cases the loader fell into the endless loop trying to look for CSS stylesheets even when all the necessary resources are downloaded. The fix contributes to the performance improvements made within this release.
• We have added the safelyExecute function into the Echo.Utils library. This method allows to execute another function in the try-catch block to avoid execution flow interruption by the code which might potentially throw an exception.
  The main reason why the function was added into the code is to avoid JS exceptions (generated by jQuery) in case the Stream app tries to assemble the UI element using the user-generated content with an invalid HTML structure. Since the Stream app doesn't control an item content format, we make sure that it doesn't break the whole app. This safety measure was applied to the author name, item content, tags and markers elements within the Stream item UI.
• The "mux" API endpoint support was added into the Echo.Stream.Server.API.Request class. Now you have an ability to use our JS API to "multiplex" requests, i.e. to use a single API call to "wrap" several API endpoint requests. More information about the Echo.StreamServer.API.Request endpoints can be found in our Documentation center here.
• The PinboardVisualization plugin docs were updated to mention that the "reTag" config option of the Stream.Item control is not supported in case the plugin is active. More information about the "reTag" option can be found here. The PinboardVisualization plugin documentaion is located in our Documentation center here.
• The "ready" callback was executed for the wrong app instance in case a few apps of the same type were employed within another app. The JS SDK code was updated to make sure that the "ready" callback defined in an App config is always executed just once and always for the proper app instance.
• We have fixed the issue with Canvases destroying. Generally destroyment process executes "destroy" method for each Application inside the Canvas. It could have thrown an exception in case the Application didn't have this method. Now Application doesn't have to have "destroy" method to work properly but it's recommended.
• Echo JS SDK tests infrastructure was reworked which allows to write tests easier and in a more readable way. It helped to expand several tests for better coverage and to reveal a few minor corner-case bugs, which were also fixed. About 50% of the current tests were converted to the new infrastructure, the rest utilizes the old test engine. We'll convert more and more tests as we move forward to switch to the new test engine eventually. Converted tests mostly use mocks to avoid requests to the real server which increases tests stability and decreases completion time by 40% approximately.

v3.0.10 - July 31, 2013

• We added the ability to override an app config using the Echo.Loader.override function in case of multiple installations of the same Canvas on a page. Now you can specify the unique id for each Canvas on the page and use this id for the Echo.Loader.override function call. More information can be found in our Documentation Center here.
• The "mode" config parameter was added for the Canvas control to trigger the type of storage which should be used to retrieve the Canvas configuration. More information about this parameter and available storage types (and their differences) can be found in our Documentation Center here.
• We have upgraded the Yepnope.js third-party library (which we use in the Echo.Loader to download the dependencies) to the latest version. It should resolve the issue with missing loader anchor element in case some other dynamic loading libs exist on the page. More information about the YepNope library and its latest version can be found here.
• In order to provide more flexibility for the CSS customizations, the Echo.Canvas class now adds special CSS classes to its target element and for each App Instance target element inside the Canvas. The CSS class starts with the "echo-canvas-" prefix and contains the ID of the Canvas/Instance and now you can target your CSS rules to a specific Canvas/Instance. You can use the Web Inspector tool in your browser to inspect the Canvas target element and find the necessary CSS base class names.
• We added the ability to define multiple app script URLs within the "scripts" in case the script should be server from different location on HTTP/HTTPS pages. More information about the new format of the "scripts" parameter can be found in our Documentation Center here.
• Sometimes if the Stream app is empty (no items posted yet), it fails to render the first submitted item received as a live update. We have fixed this issue and now all items (including the very first one) received within live updates are displayed in the Stream correctly.
• The PinboardVisualisation plugin logic was updated to disable the slide down animation for the Stream Item in order to let the Isotope library (used for the Pinboard-style visualization) work with the final state of the DOM element representing the Item, to avoid its incorrect positioning in the grid. Previously the slide animation disabling was a manual action (via Stream app config), now the plugin takes care of it automatically.
• We have excluded the "hashtags" from the list of default Item content transformations on the client side within the Stream app. Previously the "#" char was replaced with the tag icon in the item content by default. Now this transformation is removed from the default list and you can enable it using a special parameter ("item.contentTransformations") described in our Documentation Center here.
• Previously the "safeHTML" search query predicate (defined in the initial query via the "query" parameter to get the data from the StreamServer to render the Stream) was ignored during the API request to get additional replies for the item after clicking the "View more items" button. Now the same value of the "safeHTML" predicate is used across all additional requests used in the Stream app.
• We have upgraded the jQuery library to the latest v1.10.2 version. More information about the jQuery release is available in the official Blog announcement here.
• We have upgraded the QUnit library which we use as a testing framework to the latest v1.12.0 version. QUnit library release changelog is available here.