This is a very unpleasant sight for the user. In order to work around this in Angular 2+, you have a variety of solutions. The solution I prefer is to create a directive for the <img> elements on the page. If the image fails to load I show a default image that i pass in the element as a parameter. So i can show different default images in different parts of my website if I need to.

Note that this is for Angular 2+. Directives in Angular 1.x.x are entirely different. In general, directives are used to change the default behavior of an element in Angular 2+.

So coming back to the subject, I created an ImagePreload Directive:

import {Directive, Input, HostBinding} from '@angular/core'
@Directive({
    selector: 'img[default]',
    host: {
      '(error)':'updateUrl()',
      '(load)': 'load()',
      '[src]':'src'
     }
  })
  
 export class ImagePreloadDirective {
    @Input() src:string;
    @Input() default:string;
    @HostBinding('class') className
  
    updateUrl() {
      this.src = this.default;
    }
    load(){
      this.className = 'image-loaded';
    }
  }

In the decorator, I have a selector property and a host property. In the selector property I tell the Directive to apply on every element that matches the css selector img[default]. I write [default] here because I will give an attribute default to the <img> element next.

The host property gives me access to the default attributes on this element such as error, load and src. I bind them to my methods and properties on my ImagePreloadDirective class. So it means that when the default error event on the <img> element is invoked, my updateUrl() method will run too. Same goes for the load event. The [src] is not an event. Its an attribute on every <img> element. Here I’m just saying that my src property in my class should be bound to the <img> element’s src property. So if I change my property, it should change the element’s property. It might sound confusing but it’s extremely simple when you get the hang of it.

Moving on into the class, we have an 2 inputs to the directive src and default . The third one is a HostBinding. It lets you set properties on the element or component that hosts the directive, in this case img[default] .

Our <img> element in the html will now look like this:

So let’s say that the url test.com/img-1 is broken for some reason, the error event on the <img> element will fire. This in turn will fire our updateURL() method that will set the src attribute of the <img> element to the default url that we provided to the element.
In the event that the url test.com/img-1 loads fine, the load event on the <img> element will fire. It will fire our load() event and it will add a class ‘image-loaded’ to the <img> element. You can use this class to show or hide loading-spinners/image-loading-overlays.

So after you use this method, your website will look like something like this:

This is all you need to setup default image loading on your images. I like this approach because its short and simple. You can extend the functionality in the directive if you need. It only affects the elements you want and not all the image elements. It also allows you to show different fallback images for different <img> elements.

Hope this short article helped you improving the look of your website. Cheers!

The post Angular — Fallback for Broken Images appeared first on MeghRaj TechnoSoft - Web, App, E-commerce Development Agency In India..

The solution seems to be almost the same in both cases.

npm config set unsafe-perm true

What exactly is this doing? Is it ‘unsafe’?

Let’s start with a search. So there is a config setting allowed in the package.json that actually can set this per package. But wait, it’s always true unless using root. I never run as root, or with sudo privileges unless I am forced to. Let’s take a look through the source code

Set to true to suppress the UID/GID switching when running package scripts. If set explicitly to false, then installing as a non-root user will fail.

If npm was invoked with root privileges, then it will change the uid to the user account or uid specified by the user config, which defaults to nobody. Set the unsafe-perm flag to run scripts with root privileges.

function loadUid(cb) {
  // if we're not in unsafe-perm mode, then figure out who
  // to run stuff as.  Do this first, to support `npm update npm -g`
  if (!this.get('unsafe-perm')) {
    getUid(this.get('user'), this.get('group'), cb);
  } else {
    process.nextTick(cb);
  }
}

In other words, if we set unsafe-perm to always true, we will stop getting the user and the group the command was ran as and we will over-load the defaults.

'unsafe-perm': process.platform === 'win32' ||
                     process.platform === 'cygwin' ||
                     !(process.getuid && process.setuid &&
                       process.getgid && process.setgid) ||
process.getuid() !== 0,

It’s starting to make a bit more sense. This issue that I’m facing is that the permissions my current user has are unable to create the symlinks that are being asked by the program. By setting unsafe-perm to true will force NPM to attempt to always run within the context of the running script.

I suppose that this isn’t ‘unsafe’ but it does force the package installer to never drop into user and group switching when installing apps. It’s possible then you may end up having the code run as ‘root’ when installing (which could then be considered ‘unsafe’);

This goes all the way back to February 7th, 2011!
Initially this would cause the app to either Error out when false or to toggle the user and group.

But finally, we reach the reasoning for this code (and still it’s not what many may expect).

You can’t please everyone.

Don’t try to be secure if it’ll fail. 

If someone really wants to encourage this all the time, then they can do
npm config set unsafe-perm false explicitly. 

In the npm 1.0 future, it will probably require sudo for global
installing no matter what, and use this behavior for local installing.
Since so many people have npm installing in their home dir, requiring
sudo is causing more trouble than it’s worth.

Boom

This was added to help installing files into ‘safe’ locations without sudo.
So I think that I may have the answer?

Use this sparingly; probably bad to set globally for all running scripts. If the user is running as root it may cause the app to force changes that could extend beyond what a running script should have. Never run as root and it will be true by default. Use sudo otherwise. It’s not a magic bullet.

The post What does unsafe-perm in npm actually do? appeared first on MeghRaj TechnoSoft - Web, App, E-commerce Development Agency In India..