How to render individual sections in Electron desktop-class application? - user-interface

I started developing a desktop-class application using Electron, and am referring to the starter app as well as the Electron API demo app. This application has a single screen with multiple sections. Interaction within one particular section can cause other section(s) to get updated. These interactions must be in sync with an underlying model [object]; two-way data binding could be helpful here.
What is a recommended way to achieve a multi-section window with each section interacting with one another? Should I compose the layout using DIVs and CSS, or is there a library that I can use effectively with Electron? I was thinking about Handlebars or Jade but I am not sure if I need a template engine, as the entire screen is not rendered and only particular sections will be updated.

Related

How to build a paper-element app with dart?

I want to build a large application in Dart using material design. To accomplish this I included paper_elements into my project. My problem is, that I can't think of a good way to build my multi page application with paper_elements. Usually I create objects which would create their elements inline and add / remove themselves to the dom. The way I understand the paper_element tutorials I found so far this is not possible with them.
Is there a simple way to use paper_elements in dart while having an object based structure? For example I would have my application which loads either a register or login object and displays it in the browser. When logging in it should load a menu object which displays a menu and so on. All page changes should happen without a page reload.
I'm looking forward to all help, examples or links you could provide regarding my problem.
Cheers,
Tim
In Dart you normally build the app as SPA (single page application) without reload.
You can add remove a paper-element like normal DOM elements (div, input, ...) querySelector('#placeholder').append(new Element.tag('paper-input'));
You can also use <template if="{{}}"> or <template repeat="{{}}"> to make Polymer auto-insert these elements when certain conditions are fulfilled or for each value in a collection.
Your question isn't very specific but I guess all you need is already available here on SO as Q/A. Just search for [dart-polymer]. If you don't find anything just ask and we point you in the right direction.
a few that might be relevant
Dart Language: Polymer - Working with views
How to update polymer element bindings after it was removed from DOM and inserted again
How to add attributes to a dynamically created component
how to implement a main function in polymer apps (you don't need a main() when you use a polymer-element that acts as a container for your entire application)
Is imperative Mustache-Binding in Polymer.dart supported?

Angularjs and MDI SPA application with many tabs

We have to implement multiple-document-interface web application. Each document has to live in a separate tab (but on the same page, it has to be SPA). There may be up to 50 opened tabs simultaneously and application should give ability to group tab panes by modules.
One of our options were to use AngularJS for this task. We like the way Angular handles partial views, structures application by using modules/controllers and performs dependency injection.
After digging in for couple of days, we've figured out that there may be some problems with the way bindings work: there is no easy way to prevent angular from watching tabs, which contents are not currently displayed to the user. You can imagine situation when user will have around 20 opened tabs and this whole thing becomes slow as hell! Also our application is very grid-heavy, so for grids I think we should avoid ng bindings at all.
We were thinking about ng-view and the way it recreates DOM on each activation ... this looks overkill and will force us to put all UI state into the view-models, even for scroll-bars :)
Can you suggest some possible ways to improve performance with Angular and MDI? Maybe we should even consider using some other ui-framework/set of tools to achieve same results?
What's important:
modularity (AMD)
dependency injection
declarative bindings (we do like how angular and knockout solved those problems)
MVVM/MVC
ability to create multiple instances of the same controller (open multiple "details" tabs for each specific item from the grid, for example)
modularity - Angular has it's own modularity rules/patterns which are good if you want to conform to them, but if you want to make something modular in a different way, eg... allow forms to be self contained so that multiple instances of them can dynamically be opened concurrently it's quite difficult
dependency injection - Angular allows you to write code that you can inject other into, but you cannot inject Angular, it seems an oversight that you cannot test your code isolated from Angulars?
declarative bindings - yep, the way Angular binds literals within HTML with the JS code makes it really hard to create MDIs with multiple concurrent instances of a single form. You really need to dynamically create your form instances with their own identifiers (in addition to Angulars) then scope your own identifiers within the bounds of a shared set of JS files (which is what you want), however then Angular's binding will get in the way of each instance if you continue to use Angular's bindings - alternatively you can try modify the HTML dynamically get Angular to refresh it's bindings.
Basically anything to do with MDI is harder than it needs to be with Angular and it's worth looking at alternatives for such projects before hand.
AngularJS can indeed be heavy on a big application, but only when you make a change inside the $scope. The bigger part of this time is spent looking for modification by dirty checking.
If you keep an AngularJS application inside a non active tab, a dirty checking can only happen after a outside event (like a WebSocket message). You can optimize your application to remove those listener when the tab is not focused.
If you follow the best practice of AngularJS, performance issues with a lot of pages opened should not be a problem. The bigger performance problem of AngularJS come with very big amount of data inside its $scope, but there is a lot of solutions proposed all over the internet.

CanJS multiple page app

The tutorials and example I've seen are all single page application.
Can anyone give an idea or point to a resource showing how a multiple page app can be developed with CanJS?
You should be able to create a new page in whatever app framework you are using or even just static pages, and then hookup your new control and view to any element on that new page.
You want to have a separate control for each module, so you might have separate controls even on a single page if you have, for example, a filterable dropdown list, a todo list, and a login. So, in your canjs directory for your app you will have separate sub-directories for each module which will contain your control, view/s, model/s, and observe/s and unit tests. This makes them re-usable, easier to test, and since they are modular if one part of your app breaks it won't take down all functionality. Once you get the hang of that incorporate AMD style loading of your assets with stealJS which is made by Bitovi - the CanJS creators.
https://github.com/bitovi/steal
If you want to manipulate the location.hash without actually changing pages or manaage browser history and client state you should check out can.route:
http://canjs.com/docs/can.route.html

Portal type application with AngularJS (Multiple Independent apps)

We are trying to create a portal type application with multiple / independent "sub-apps". Assuming that all sub-apps are written in Angular what is a good pattern to achieve the following goals.
Each app can be developed and deployed independent of each other.
They share a common authentication service, they can share common libraries (directives, filters etc).
Only one app will be visible and active at any given time. The scope of each sub-app is isolated from each other.
When the users goes between the sub-apps, the state is maintained as long as the user does not refresh the page or visit another static link. (I think this is built into Angular and no special effort maybe needed)
Each sub-app will have more than one views (it will have its own menu). There will be a top menu based on what sub-apps are available. Ideally the top menu is dynamically build based on what sub-apps are deployed. Maybe there is a server side component to this (the server detects the folder structure etc and determines what apps are deployed and injects the necessary js code into the page).
Given the fact that AngularJs does not have multi-level view structure, I was thinking of using multiple ng-app declarations on different divs and then using $window scope to store the key of the active app and hide the ones which are not active.
There is no easy answer to your (rather open) question, but regarding the $route and ngView limitations, I have been having great success employing a technique derived from this: http://www.bennadel.com/blog/2420-Mapping-AngularJS-Routes-Onto-URL-Parameters-And-Client-Side-Events.htm
This is something that I also have been thinking of trying to implement. While I don't have a complete working solution, I believe that this type of portal app would consist of multiple angular apps on the same page.
The portal app would be the traditional ng-app directive on the main page and the "portlets" would be dynamically created and manually bootstrapped angular apps on a sub view div. You can share data, state, authentication, personalization, etc from injecting the portal services (contained in their own module) that provide these features into the manually bootstrapped portlet apps.
The tricky part is how the portal app would discover the portlet apps and serve up their angular modules knowing that these apps would be independently deployed web apps with their own urls.
I still have some questions around if the service data would be common between the apps or if you would need to try and leverage HTML5 local storage via the portal service (like a data manager).

When to use more than one Sammy.js application?

As I'm learning about Sammy.js I read that you can have several Sammy.js applications in the same page, each bound to a different element (i.e. div). I would like to understand why would this be useful.
I read in another post that only forms inside a bound element will trigger the route change, I'm thinking this could be used to modularize your application. Is there another use case beside this? Could you provide an example of how to modularize your application in this way?
We implemented a component similar to Sammy in our Silverlight application some time ago. The similarity is in that both represent a kind of a simple browser that can be bound to a UI region. The approach gave us several benefits:
We had an extensible way to add new content implementations. I mean that we could add plugins to our app that contained new forms/views which the application core had no knowledge about.
We could easily implement composite views, e.g. dashboard that were able to show any view implemented in any module. Including themselves. (A-ha, we had created recursive dashboards that worked until the app hit the memory limit. Kind of Inception. :))
Sammy can be used to reach these goals as well.
However, you must understand that from all Sammy applications running on a page, only one can be bound to the browser location bar. Others will have their location visible only to javascript, or you'll need to render location bars for them on the page.

Resources