If you have an existing angular application, that already have localization working (i.e text load in different languages) if one of those is RTL direction (Hebrew/Arabic etc) how would you go about writing the code for that?
Remember it's not enough to change the dir="rtl" on those warpper/html. For example elements in nav bar have to be mirrored and floated to right.
Popover (when you hover elements) need to change direction and so the list goes on.
Approaches tested for accommodating RTL:
1.
Setting text direction BEFORE we load the app in our app-load module (Using app_initializer)
In that function we can set the dir attribute on the HTML and lang
Based on the user's local language
Later when we bootstrap our angular application we can look into that html attribute
This (1) I like and want to keep doing.
2.
Using only css/less/sass to change the looks of the site after we have 1 working
Those styles (as we want) will only get applied for languages with rtl direction
But when we tried to rotate (mirror) nav links (in header) and change popover directions things got very tricky.
The order of elements in the html as well as the styles need to change, and for some components the changes were significant, therefore we tried approach number 3.
We can still leverage using this approach with the next ones (combine them) so this is still useful.
On more specifics what didn’t work with less was the use of dispaly: flex on a wrapper elements
With combination of :nth-child(i)
Selectors with order: j;
To rotate elemenst in nav bar
Only things like float: right were successful
Also tested some
-webkit-transform: scaleY(-1);
With combination of display:inline-block;
3.
If we could have a simple way to dictate which templateUrl we load into the components
We could then have for A.compoenent one a.html template (default ltr direction) and another
A-rtl.html based on a condition.
See fore ref:
Angular 2 dynamic template url with string variable?
Essentially splitting the templates into 2 but the HUGE benefit would be that we can have the .ts code once
This will be greatt but I can't get this to work.
Even if it’s possible it seems that it will prevent AOT compilation. (or not?)
See for ref: (old post but still relevant)
https://blog.lacolaco.net/post/dynamic-component-creation-in-angular-2-rc-5/
The angular official documentation approach
https://angular.io/guide/dynamic-component-loader
This is working! The issue is that this isn’t exactly what we want. In this approach we load separate COMPONENTS into a placeHolder and not separate TEMPLATES
4.
This approach is to use *ngIf on the template wrapping our ltr (current template) with
And adding a seperate one below it with
There will be some duplication in this case, but this isn’t really code (it’s HTML) it’s simply markup, plus like this we have much more control on how things look and where, and if we need to use for example popover-rtl component instead of the current popover (which again isn’t currently compatible with RTL) we can EASILY do so.
In this approach there are several simple approaches to determine for every component if we are on ltr or rtl text direction (for the ngIf)
In short is using a baseComponent, or a service.
Note: both approaches 3,4 can use what we did in 1 and 2.
Any suggestion on how to get approach 3 working?
Ideally I can get a condition to determine which templateUrl I should load for the component so the the code in .ts is there for both and only markup is different.
Please suggest on Annular 6+ version if possible.
P.S been using this site for over 10 years almost every day and that is my first questions, thumb me up please :)
Thanks!
although a long time passed from your posting:
create a base component, that will hold all the logic.
create as many components per your liking (one for RTL, one for LTR etc). each component will inherit from the base component. each component will have it's own HTML template, styles etc.
you select which component to show, via routing, ngIf or whatever suites you needs.
Related
Say you are passing a prop called show to a component. If the prop value is true, you should render the full component normally. If it is false, you should not display anything.
You can do this two ways.
return null in the render method of the component.
apply a CSS class containing display: none attribute to the component's DOM element.
Which ones is the correct or the preferred way?
I do not think there will be any definite answer for this question.
Each approach has its benefits and drawbacks.
With CSS you have:
it might work faster
no need to think about restoring child control states if control is shown again.
With returning null:
the total rendered DOM might be considerably smaller. This is important if you have many such components that might be hidden.
there will be no collisions in rendered html. Lets say you have tabular view. Each tab is its own complex form with many child controls. If you have some raw javascript/jquery/whatever working with their ids/classnames etc. - its quite hard to ensure each tab/form has unique ids, unless you do not render them.
From my point of view the decision will be based upon the structure of your control. If it have complex structure with many nested children and you do not have any means of restoring their states when switched on again - go with CSS, but I would say this is a short term solution for quite simple controls only. In all other cases I would go with not rendering a component.
If you think you would need to display the component again, during that page life, then I would recommend using css way, as the impact on DOM manipulation would be less in that case. In some other cases probably returning null would be more helpful.
For the most part, your two solutions are interchangeable. They both "work" fine.
I would warn against preemptive optimization in choosing which of these methods to choose. If you do need to eventually modify your code and try the other method, this is an absurdly simple swap to make and shouldn't be an obstacle. So don't worry about it until there's a reason to worry about it.
I'm the OP.
If components are hidden depending on the screen size, CSS media queries and display: none works the best if the app is pre-rendered using something like react-snap. This is because, if the pre-rendered device and the viewing device don't match, the layout would change when the app rehydrates if the component hiding logic is in JS.
Related to that, we need to be careful that even though the component is not "shown" with CSS display: none, the component is still there and if there are effects, they will still fire.
Im using Bootstrap and AngularJS with .Net Web API for my backend services. Im still a bit new to AngularJS. When considering the different sections of the layout, my app directive is currently at the container level named "Bottom". However, my individual views will be in the area named "main-content" (these are div boundaries).
The layout also contains an area named "sidebar" which will only be used on one page, the rest of my pages will expand "content-wrapper" from 10 to the full 12 column width of the page.
So Im trying to decide on how to use either use one layout (in terms of our MVC _layout.cshtml typically used for the template) for both types of pages, or use two separate layouts. The latter seems "cleaner", since trying to use a single layout for all scenarios seems more trouble. I think Ive used separate master pages with ASP.Net web forms in the past in these cases. Same idea here? I think this would make things cleaner also with regards to setting up the AngularJS code, as I can separate the two page types with different modules with their own controllers. Does this seem like a good approach, considering not just the mvc layout, but any impact on Angular/Javascript code?
TL;DR: Use one layout CSHTML page.
It's hard to give a confident recommendation without having a deeper knowledge of your application. Ultimately, it's your decision to make based on the information you have.
That being said, if indeed that sidebar is only used on one page, it should be considered part of that page. With that in mind, Container in the image you attached would serve as the host element for the router's view directive and the page with the sidebar will have that sidebar in its template.
If, however, the sidebar may appear on other pages in the future, I would simply hide it based on the current page with the view directive on the content-wrapper in your example. I have a similar situation in an app I'm working in which the sidebar behaves as a sort of internal navigation. If the current page does not have any sensible links to put in that sidebar, we hide it. Something like that may work for you in this case.
In either case, I would recommend against using multiple CSHTML layout pages because of the potential strangeness in the user's experience with some pages using a nice, AJAX-driven navigation and others using an old-school, "white-flash" kind of navigation.
Take a look at ui-router, which is an alternative to the default routing that Angular comes with. It allows you to have multiple views, the content of which can change based on the route. If you are used to using a templating system to layout applications pages and your pages have a generalized sort of layout (ie all pages have a top nav, a main body, and a footer, or something similar) then ui-router goes a long way towards making this much easier in Angular.
I would like to ask if there are any examples related to Polymer's animated pages ( http://www.polymer-project.org/docs/elements/core-elements.html#core-animated-pages ) and how we can build a similar demo using the resources provided in the Angular/material repo (https://github.com/angular/material).
I would like to achieve http://www.polymer-project.org/components/core-animated-pages/demos/music.html but I don't want to use Polymer since I would like to use Angular.
Can you please provide me some directions in order to start?
What they typically do with Polymer is have two connected elements which shows only one and when you perform some action, the other gets shown (from display: none) and animates from certain dimentions to its final form. Sometimes elements also shift but it depends on whether the content is able to move to its new position or not.
You have to work with css transition, transform and display. Sometimes even custom animations. And you are mostly changing multiple divs to their final form. I think the most difficult would be animating colors (from white to pink or from yellow to green for example) as those are most difficult to do (performance-wise).
If you look at the example you've set (final link) you see there's a list of items with a detail div and once you click the item you show the detail and transform the contents to its final dimentions.
Just know that these things are pretty hard if you aren't very much into Angular or HTML/CSS/Javascript.
The framework of Polymer for Web is very much a work in progress and i wouldn't be surprised if it took a few months to get similar results for both native and web.
You can take example from things like this: https://medium.com/tictail-makers/giving-animations-life-8b20165224c5 or https://www.polymer-project.org/apps/topeka/ or http://codepen.io/collection/amheq/ . And don't forget to speed it up by using some bootstrap theme like this http://fezvrasta.github.io/bootstrap-material-design/ or something.
I've been struggling with the same problem as there isn't much to go from right now. You stated the Angular project but that will take time. If you want to do it now, you have to do quite some work (if you do, share it with us), but you might be better of with postponing this until most of the bugs and problems have been solved.
Thats what i'm doing now.
I would like to offer my users the ability to customize the look and feel of the website.
I am giving them a color picker to choose a color scheme. I would like to dynamically generate few matching colors and apply them.
My questions are:
1.) How can i generate a color scheme based on the choosen color ? (some matching colors and contrasting colors for the background)
2.) What are the best practices for achieving a themable interface ?
I am writing an AngularJS SPA app with pure HTML with REST API as backend.
Right now for my 2nd question, I am retrieving the color setting and applying them for body.
<body style="background:color:{{bgcolor}}; color:{{fgcolor}}">
I am looking for something more elegant.
You can do this with ngStyle as you have above... but as you noted, it's not very elegant.
The simple truth is that nothing in AngularJS itself is really designed to address this problem other than the ngStyle directive itself. However, while I haven't exactly seen a "best practice" for this, you might take some ideas from Drupal's "Color" module, which is one of its base/core modules. You can do the same thing in Angular very easily.
What this does is go back to stylesheets, which I'm assuming you skipped over because it didn't seem like an obvious solution for something dynamic. But they have a clever answer. In a piece of code, after the user picks a color, they write out a stylesheet with a unique ID for its filename. They put these in a directory where other user-uploaded assets are kept, so they don't mix with core site code (minimize the potential attack vector). Then they only need a simple rule in the page to include the stylesheet itself.
You can easily emulate all of this with Angular, although you'll need your server's help, of course. But the nice thing about it is it's much easier for you to maintain. Instead of having to "sprinkle" ngStyle directives all over the place (one on everything you want styled) and potentially having conflicts with other things you want to do on some of those elements, the stylesheet can work exactly the way it's supposed to: using classes to target specific elements. You can make a template stylesheet that's easy to maintain, so that's a natural fit... and the best part is, it's easy to hook everything up.
I understand that content, presentation, and behavior are supposed to be separated by using HTML, CSS, and JS to implement them independently. Is there a best practice for binding these elements concretely while maintaining loose coupling in a dynamic web app? Is it even possible? Optimally without depending on jQuery?
To clarify what I'm talking about: HTML has no mechanism for the definition of new tags, so when your JavaScript model needs to generate content, the tags and structure for its presentation are necessarily defined in JS or somehow made accessible to it, tightly coupling behavior to content.
Before someone calls over-OOP, the reason I want to keep tags and CSS classes out of JS is that I don't even want to commit to HTML as a front end. There are at least five different representations of my underlying model that I'll eventually want, and tightly coupling the model to HTML rules out at least two of them.
Is there some way to late bind the model to the target representation without sacrificing dynamics or loose coupling? Like an XML document corresponding model elements to template HTML snippets?
UPDATE
Though it seems backward to provide concrete details of a question about factoring and OO best practice, I want to provide a much fresher example of the entanglement of form & function inherent to HTML. The entanglement of content & behavior between HTML and JS is the problem, though, not the example, and I want an answer that doesn't break when I change the details. It's from a very different project than the one I was working when I first asked this question, but the gist is the same:
I have some HTML for a UI widget. It is a view that represents a model object - a selection of palettes - to the user. Palettes themselves are part of the app's task, so they're not view, they're model.
I want to use this widget in at least 2 different dialogs (and any I might want in the future). In one, I need a changed selection to cause immediate action, the recoloring of a set of images in canvas elements that are part of the same dialog. In another, I just need to have two different sets to select from - one selection in each set.
I do not want to copy and paste this widget's HTML form or JS behavior because I want maintenance and revision to propagate from one base thing to all of its instances. Thus, only one instance of the widget, whatever its form may be, may exist in my source.
I do not want to have my JS rendering HTML tags directly because doing so will forfeit my IDE's error checking and content assistance on the HTML. Further, if there are problems with the HTML output, their source in my JS will be less clear because the process of generating the HTML doesn't look like HTML or necessarily reflect its structure. Finally, I want to test the effects of changes to the widget's CSS and HTML independently of my JS.
I do not want to involve additional dependencies e.g. separate templating & parameterization languages in my source because changes to various standards or evolving needs may break their compatibility, or they may themselves become unmaintained, in the future, leaving me with a massive quantity of useless source. Depending on jQuery is okay because it does more for normalizing between browsers (not to mention for convenience) than it is likely to ever break given its ubiquity, but other libraries will be regarded with extreme suspicion.
I want to specify the details of altering and retrieving the widget's state (what colors compose the palettes, how the user chooses among them) in JS that references only the widget and its component parts, since it's going to be a part of multiple dialogs that use its information in different ways.
Simultaneously, other JS code (the dialog's behavior) needs to be able to observe and initialize the widget's state - but without including any specific references to the widget's internal structure, which may some day change to accommodate new features, fix bugs, etc.
For simply making multiple copies of the widget's HTML, I can settle on calling jquery.clone on a template node that exists in an HTML file, and inserting the contents where I need them, from the function that sets up the dialog. HTML makes things difficult when any of the cloned elements have id or name attributes, but careful handling during cloning can make unique identifiers, point their corresponding label elements and href attributes at the new identifiers, and keep the old ones accessible in data attributes. So all is well and good for structure & content, and obviously the CSS presentation propagates to the clone just fine.
The rub comes when I try to implement the widget's interface with its dialog's controller. What is the most future-proof way to expose the widget's state's abstraction? I.e. I don't want to use widgetJquery.find('input:checked').val() to get the selected color from code that doesn't absolutely have to commit to a selection being based on a checked input element whose value attribute is a set of serialized colors.
I hope that makes it more clear what I'm looking for without muddling the question with details.
You can always have different XSLTs parse an XML.
But, it seems you try to abstract tooo much.
use the MVC, use different views to parse.
The methodology you write about is common in old systems, I worked with more than 10 years ago, there is probably a good reason evolution killed it.
Loose coupling is best achieved archtecturally using design patterns. A great example of how to achieve loose coupling is found in the Mediator Pattern. However, there are several patterns to use.
I suggest reading Addy Osmani's 'Essential JavaScript design Patterns' for comprehensive coverage of a range of patterns.
Enjoy!