As far as I can tell, most of the talks and resources on Polymer cover fairly trivial cases of data binding.
However, Polymer is a powerful tool that can in principle be used to build things like IDEs, WYSIWYG editors, or even simple games; as long as the total number of elements on the page is kept fairly small (certainly <1000, but ideally <100).
However, in these examples, the graph of data bindings can become very complex, and the results of a single event (e.g. a mouse click) can propagate/reverberate around the binding graph in hard-to-comprehend ways.
So, the question is, firstly are there any resources (videos/blogs etc.) that discuss best practices etc. for these types of complex scenarios; and two is there any chance of having a tool which generates a graphical representation of the binding graph. Ideally such a graph could be rendered in the page, superimposed on the elements themselves. In fact, one could imagine having a "record" feature, that tracked data propagation during an event and generated a GIF showing the data moving around the graph.
This may not be an ideal question for SO, but it didn't seem right as an issue on github either.
That's the reason why you should use an external state management framework such as redux for complex apps.
You can use the polymer-redux behavior which is a simple behavior that allows you to interact with redux.
You basically split up your components in Presentational and Container Components. The presentational polymer components are your leaf components that are unaware of redux and only take in data and emit events. The container components implement the redux behavior and dispatch actions for state changes and pass data to their childs (usually presentational components).
The state is stored globally and all the state modifications happen in reducers that you can easily unit test. The advantage is that you can use the redux-devtools to do time travel debugging and also visualize your state as a graph
Related
Is there any way to load an angular component in isolation for design & testing purposes? I am attempting to redesign some components for a fairly complex angular app (it was started in angular2-rc and although it has been updated it's still following some bad design patterns - mostly due to work previously done by inexperienced devs on unreasonably tight deadlines, needless to say we are now developing this in-house). This makes it difficult to access certain nested components.
Currently my workflow for designing and testing a component is as follows:
Run the backend app (because of authentication checks etc. - the app is entirely private so needs a valid login to access anything)
Run the angular app (ng serve handles this and will obviously auto reload on change)
Log in to app
Navigate back to the relevant page (due to the login redirect taking me away from the page I was on)
Fill in the required data on the page to get to the point where my new component would show in a normal use case
Design/test/etc my new component, making any necessary changes
if (!done) { goto 2; } else { return; }
This seems excessive for designing a single component. There must be a better way to simply load my component directly for design and testing purposes. Ideally I would like my workflow to be something along the lines of:
Load the angular component directly instead of having to run the entire app (preferably with a way to mock any necessary inputs, services, etc)
Design and test component to ensure desired layout, style, functionality, ux, etc - making any changes as necessary
if (!done) { goto 1; } else { goto 4; }
Integrate component into app
Is what I'm looking for even possible? Surely I'm not the first person to run into this problem - UI frameworks are the first come to mind given how they provide a library of generic components to drop in wherever necessary.
Am I missing something? Or is the only way to do this just to create a simple mocked test app and drop the in-dev components there for quick and easy access?
Update
To clarify, I'm specifically trying to rapidly & iteratively design this component from a mostly visual/rendering perspective. I need to ensure cross-browser consistency, responsiveness at different screen resolutions, elements not overlapping incorrectly or rendering offscreen, colors/fonts/sizes/positions are appropriate in the context of the component (eg. <h3> is too big and looks out of place, lets try <h4> instead and see how that looks) etc. where the component has nested components which need to be displayed.
I tagged the question with html & css intentionally - not because those are the languages the component uses, but because those are the aspects of the component I am trying to test.
Thanks to those who have helpfully pasted a link to the docs (which, yes I have read) explaining how to unit test the component and briefly describing how to test certain rendering conditions based on the code (applied classes, attributes, styles etc). What I was unfortunately unable to find in there are tests such as:
expect(myComponent).toDisplayIdenticallyAcross(browser.Chrome, browser.Firefox, browser.Edge, browser.Safari);
expect(myLabel.color).toContrastWellWith(myComponent.backgroundColor);
expect(myNestedComponent).toRenderEntirelyOnScreenWithoutOverlapping(true);
That is to be expected as these are more subjective things which can really only be tested by looking at them and making minor tweaks as necessary. I'm simply trying to find a simpler way to do that without having to reload the entire app a minimum of three times just to see whether having my heading left, center or right aligned looks better.
I think it's hard to do unit testing on visual characteristics like you describe in your edit. I've never had to do that for a react app, generally you build a component and worry about what it looks like, and partially worry about it's layout, and it's parent also handles part of it's layout because the layout can vary on different pages but the component itself should still visually look the same. Also if you don't want to keep refreshing the page you can use chrome dev tools to update the css and see how it looks, then when you pick something you like, apply it to your actual code
Components are just classes. And they can be tested as such.
More
https://angular.io/guide/testing#component-test-basics
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.
We are about to break our controllers up: actions that return semi-static HTML pages, actions that return JSON ViewModels and finally actions that post changes. We plan on using JSON.NET to do the JSON serialization since it supports a spiffy LINQ-like syntax for creating complex JSON objects. We will use jQuery+AJAX to call the JSON actions and use the results to replace elements in the HTML.
Before, we were passing ViewModels to the View() method and using it with Razor to fill in the screens. So the real big difference is that our view models will be JSON objects and JavaScript will be building the pages. The problem with the Razor syntax was that it was acting as a crutch. A lot of times we were mangling Razor and JavaScript (Frankenstein). Plus, a few pages take long enough to load that some sort of up-front feedback is needed anyway (loading...).
To the question: I have been looking at my code and have noticed that many ViewModels share common properties. Furthermore, the same logic is appearing across multiple controllers. I have been wondering what patterns/tools are out there for putting this logic into one place. Also, should I be trying to create a "master" ViewModel with child ViewModels (with other child ViewModels and so on)? The idea being that some elements are shared across all pages (such as header and footer content) and so it would seem to make sense to have a common ViewModel structure for each page. That way I can reuse the some JavaScript for finding data and setting it in the HTML. I figure if a page doesn't use a child ViewModel, I would just pass null, so it wouldn't take up too much space.
I want to make sure that I get things right before I start going down this new path. I have seen applications that use the hierarchy of ViewModels before and have seen problems because of it. I also want to keep the number of AJAX calls down, so I want to return as much data as possible in as few calls as possible. They are kind of contradicting requirements. I was hoping someone had experience with building lots of ViewModels and and with converting these to JSON objects for consumption on the client side. I was also curious if anyone found any tools for JavaScript for building pages from ViewModels. We are looking at backbone.js right now, but it seems oriented towards forms rather than generic content generation.
The idea being that some elements are shared across all pages (such as header and footer content) and so it would seem to make sense to have a common ViewModel structure for each page.
You should consider using partial views and master pages to accomplish this if you aren't already. Both are very useful and powerful tools.
I was also curious if anyone found any tools for JavaScript for building pages from ViewModels.
An extremely powerful JavaScript library that uses the MVVM pattern is Knockout.js. The twenty minute introduction video on the home page explains it very clearly.
I have to make an iPhone app for a company which has a web based system, and wants to go mobile. Its known in advance that the UI of the screen will change fairly often (adding new labels, buttons, etc). Also, many elements on the screen have an If(condition) then (visible) else (hidden) type situation. For instance, if(user.isMember) then (showLoginButton) else (showRegisterButton) All this is a fairly common scenario for companies who want to take their we-offering as a mobile-app.
The challenge now is how to write a flexible UI. If I go the standard UIView type approach and add labels, buttons etc, it becomes static in nature. Further, since a lot of elements (for instance, in the above example, loginButton, registerButton, retrievePasswordButton) are overlapping (since they should be on the exact location on the canvas), the Interface Builder looks cluttered.
One solution I can see is to use HTML content in UIWebView. Considering HTML browsers were defines with the concept for Forms in mind, it makes logical sense. There would be some overhead of doing search/replace for the values in the locally stored html file (call it template now), but guess the flexibility provided will be worthy of it.
I would like to invite pros/cons for this approach, and any other approaches that may have worked for you in the past for making flexible UIs.
There are at least two basic approches, among many.
The first, as you mentioned, is to use stored HTML5/CSS/Javascript for each form, and run them in embedded UIWebViews. But there is no need to do search/replace on the device. Instead of modifying a template, just download a entire new "web page" for any form that has to be changed or updated. Very flexible, if all the elements you require are efficiently "webifiable".
The second approach is to use a Data Driven UI (there's an Apple WWDC 2010 video on this technique). Basically, for every view and every UI element, instead of putting it in a nib or creating it from hard coded parameters, you read a r/w database for everything needed to create the element: size, position, title, color, value, what method(s) it calls, etc. To modify, you download updates to this database.
If you need an updatable "native" UI plus application logic, you could use a mix of the above two methods: a Data Driven UI engine with optional string parameters consisting of Javascript for any object to call for custom logic, calculation, state changes, etc.
Summary for the impatient:
What I want to know is what you want to have in a new gui language. About the short answers mentioning $your_favorite_one; I assume you mean that, such a language should look like $your_favorite_one. These are not helpful. Resist the temptation.
I'm thinking on the user friendliness of XML based languages such as XHTML (or HTML, although not XML they are very similar), XUL, MXML and others ("others" in this context means that, I am aware of the existence of other languages and their implementations alternative to their original ones, and the purpose of the mentioning only these languages by name is, to give an idea of what I am talking about and I don't feel like mentioning any others and also, I see no point in trying to make a comprehensive list anyway.). I have some opinions about what features should such a language have;
The language should be "human writable" such that, an average developer should be able to code a good amount without constantly referring which tags have which properties, what is allowed inside what. XHTML/HTML is the best one in this regard.
There should be good collection of controls built-in for common tasks. XHTML/HTML just sucks here.
It should be able to be styled with css-like language (with respect to functionality). It should be easy to separate concerns about the structure and eye-candy. Layout algorithm of this combined whole should be simple and intuitive. Why the hell float removes the element from the layout? Why there is not a layout:not-included or something similar instead?
I know that I don't even mention very important design considerations like interaction with rendering engine and other general purpose languages, data binding, strict XML compliance (ability to define new tags? without namespaces?) but these are the points that I would like to ask what you consider important for such a language?
There will always be a tradeoff between ability and simplicity.
Personally I'm happy with the features of WPF (which uses XAML) for MS development. I dont find its complexity to be a barrier to developement at all.
However if your going to target your toolkit/language to a demographic that requires a higher degree of simplicity, you could possibly get away with leveraging an existing framework and provide the end user with a DSL specific to their needs.
Writing a new framework for the dev community as a whole is a mammoth undertaking though, and I suspect you will find that due to the wide range of features required that you will have to deal with a large degree of complexity at some point. Best of luck.
Most recent XML GUI language (not only for GUI actually) is called XAML. It has all that candies: styles, layout definition, objects initialization, etc. But it's a pain to write more or less large XAML files. Auto-completion helps but the core problem - forest of angle brackets - is not solved. Another problem with advanced XML-based GUI langs - they try to serve to several purposes at once, but XML syntax is not suitable for all situations. For example XAML supports data-binding, but why the hell I should write it in attribute string? It's first class feature and should have proper support.
IMO all modern XML-based langs suck terribly. Language intended for humans must not force it's users to write tons of brackets or do deep tags nesting. It must be user friendly, not computer friendly. My dream it to have GUI language with Python-like syntax.
In conclusion I want to say:
Dear XML-based langs authors, please be humane, don't create another language based on XML. Read some good book on Domain Specific Languages and please, don't make me type < and > symbols ever again.
You should have specified whether you mean web or rich client, but either way take a look at XAML/WPF. If you're anti-MS, then look at Moonlight, the Mono implementation of SilverLight.
I would like it to be easy to connect to any database, perform queries that return a recordset, and be able to parse and iterate easily said recordset to display its data in graphic controls, for example pie-charts, bar-charts, timeline charts (stock options like), node graphs with animation effects, all this at run time.
Easy mouse events catching, to implement any action on rollovers, mouseins, mouseouts, clicks, drag and drops, clipboard management, etc. A good infinite zooming capability would be great too.
I don't want to set a "datasource" that establishes a fixed connection between some column in my SQL query and some displayable element at design time, I want to perform any query that I want and show elements tied to any query field, anytime, in run time. I don't want to be only able to bind a datasource and displayable elements at design time.
css style capability for everything. Or something as simple and easy.
resize and layout taken care of automatically. Easy access to local files, to parse, play, display. Easy classes for image management, supporting transparency, resizing, etc. Basic and advanced classes for drawing in the screen: lineTo, rectangle, circle, animations. Even 3D.
Embedded fonts functionality. I don't want to worry about "will the user have this font installed?" Also I don't want to worry about DPI or screen resolutions.
Basic widgets: treeviews, etc.
A good designer. I don't want to add widgets writing the code. I want to place them visually in the screen.
Also, it would be good if it could connect to dlls made in C++ or COM objects in general.