Completely different view for mobile - javascript

I have a SPA that needs to display my app in two completely different ways depending on the client device.
One shows a floorplan of my house with lightbulb icons to switch on/off my lights (and later on more information), rendered on a canvas using isometric projection.
The other (mostly for mobile) shows the same lightbulb icons alongside a name in a simpler list/hamburger menu.
I don't want to limit either device-type to the view I intended, but what is the best way of completely replacing the component based on device/selected view?
Should I create two components and move shared logic to services/classes? Or should I hide the unneeded component (I don't want to waste resources rendering the canvas or running the logic needed to render it)

If you use *ngIf or similar, then there is nothing rendered if the expression is false while [hidden]="..." causes HTML to be rendered.
Moving logic to services is a good practice anyway.
You could also load different router configuration depending on the view size
See also New Angular2 router configuration. This way you could load entirely different components for different view sizes.
(It looks like this will be improved in next versions for example to only load new child routes for a component, there are also discussions to provide an API to allow to add/remove single routes)

Related

Angular 6 - Best way to implement complex template

I'm relatively new to the Angular 2.0+ world, and I'm facing a question about template design. I'm sure there's an Angular way to do this; I just didn't find a clear answer yet.
So, the idea is that (see the attached image) I've the red component, that has to be included in many parts of the application. The red component has some styles, inputs and outputs that are gonna be the same for the whole app. But inside the red component there must be embedded three components that will vary depending on where the red component is placed.
For example, imagine the red component is the container for a detail page. If it's placed in the detail page of the entity A, green component will be a map, yellow an image and blue a read more button. All of those components must have inputs, outputs and probably references so they can be manipulated using view childs.
If the red component is placed somewhere else, then those three components will be different. And there could even be just 2, not three components.
Does someone has a clue on how to design the red component so it's reusable and can fit my necesities? Thanks a lot, and please let me know if more explanations are required for my problem to be understood.
In this case you can use named ng-content, where you can more than one component as its container data and pass input/events/style or whatever you want to pass for example -
<red-component>
<yellow-component></yellow-component>
<blue-component></blue-component>
<green-component></green-component>
</red-component>
https://medium.freecodecamp.org/everything-you-need-to-know-about-ng-template-ng-content-ng-container-and-ngtemplateoutlet-4b7b51223691

Angular 4 - it is more expensive to handle styles of a generic component or work with specific components

I'm working on a hybrid application for which I need a toolbar. This toolbar must handle different forms and functionalities, in some cases contains a title, other buttons and links and in others an autocomplete, then my questions is if is more efficient to build a dynamic component that accepts all these elements or work on different toolbar's that will be inserted and removed from the DOM as needed.
Thanks!
A dynamic toolbar will be faster, because angular wont need to re-render the whole toolbar each time it changes. It's smart enough just to find the stuff it needs to update.
Also it will make your code easier to maintain I think. Having multiple toolbars, probably with some shared logic/elements will cause repeated code.
Also you will probably have less lines of code with a dynamic toolbar, perhaps slightly reducing the size of your project. I suspect that wont be significant. Honestly, I think the biggest advantage wont be speed but cleaner, more maintainable code in general.
It depends on whether you are using lazy loading or bundling your entire App in one main.bundle.js
In the first case, you want to ship the strict minimum to the browser as it's needed. Therefore, you want separate component for each use case.
In the second case, it makes your app lighter to create on single component to handle different toolbar use cases.
To demonstrate this, (assuming you're not using lazy loading) you can create a small project with a main component which uses 2 different views.
In one case you create a single component for each view.
In the other you combine both views in one component.
Then build and serve both and you can see the difference in the weight of your JS files.
Hope this helps

How to optimize the rendering of components in Ember JS

There are around 3 hundred components rendered inside the wrapper component and its taking to much of time to render. But I need thousand of components to get rendered inside the wrapper container. How can I achieve this without any performance issues while rendering the components
Image shows the rendering time taken by 300 components which is too much
If you have a scroll and all of your components are not in the viewport at the same time, you may use the Proxy Pattern.
There is an ember addon called ember-in-viewport to detect whether your component is in viewport or not. By using it, you may implement the proxy pattern.
Here is a sample twiddle. At the application.hbs, if you use my-proxy-component instead of my-component, page rendering would be nearly 3 times faster.
These tips are kinda hacky but might help:
You might want to lazy load some of the components, like for example load the most critical ones and then load the rest changing a computed property after a fixed timeout on didRender event (during the idle state).
For example:
onDidRender: Ember.on('didRender', function() {
Ember.run.later(() => {
this.set('displayLazyItems', true);
}, 2000);
})
Another thing you might want to do is inline code instead of creating a new component for small items. Rendering those might take some serious time.
Record a timeline and ensure that the performance is actually coming from render time, sometimes is actually some javascript execution or loading that is messing up.
Lastly, ember 2.10 includes glimmer 2, this new render engine can optimize render time up to 50%, you might want to consider using it.

React different representations of same data, parametrize container component render

Is it an antipattern to return different representation component elements from container based on some condition variable passed to the container?
I have routes for SummaryPageComponent and CustomersPageComponent. Summary page has a partition which presents chunk of the same data that Customers page shows in more detail. It would be redundant to create two distinct container components containing the same data and logic just to pass that data to different representation component. Including logic to representation component isn't an opinion either.
So my question is, would it be acceptable to create a container component which returns either <CustomersSummaryComponent> or <CustomersDetailsComponent> based on some prop (summary=true/false for example) passed to it? That way I could include the Customers domain anywhere in my SAP and parametrize it's presentation the way that fits. Is this advisable or does it make code too hard to maintain?
good thinking it is okay if done using High order components (HOCs) cause you can reuse the logic. eg a YouTube player can show small and large screen without the displaying component not knowing how to do it but just respond to behavior change in screen size, use High order components to abstract the logic: https://github.com/mathieuancelin/react-conditional-render and
https://medium.com/#franleplant/react-higher-order-components-in-depth-cf9032ee6c3e#.hebgpvtup

JavaScript / Backbone.js layout manager

I have a number of (Backbone.js) Controllers with a bunch of child elements.
When the browser is resized or the model changes, I'd like child elements of various controllers to be able to affect the layout of other elements.
Let's say for example that I change language in the model and that this results in my headerController => titleTextField growing from 1 to 2 rows. This should cause the container below to shrink to accomodate for the growth.
Somehow, I'd like a layout manager to be able to take this into account and reposition dependent elements accordingly.
Are there such layout managers? Alternatively how would you build one?
(Preferably one that works well with Backbone.js MVC principles)
this sounds like a CSS issue, not a javascript / mvc issue. there are plenty of css frameworks out there, such as 960grid, blueprint, and many many more, that handle this sort of layout change

Categories