41 Matching Annotations
  1. Dec 2018
    1. Then inject it inside a test by calling TestBed.get() with the service class as the argument. it('should use ValueService', () => { service = TestBed.get(ValueService); expect(service.getValue()).toBe('real value'); });

      this is for testing the service, directly

    2. However, you almost always inject service into application classes using Angular dependency injection and you should have tests that reflect that usage pattern. Angular testing utilities make it easy to investigate how injected services behave.

      key point

    1. We can even remove the AuthService import if we want, there really is no dependency on anything else. The LoginComponent is tested in isolation:

      that's a key point - isolating stuff. remember this is unit testing, not integration tests. we wish to have as little as dependencies as possible.

    2. That’s not very isolated but also not too much to ask for in this scenario. However imagine if LoginComponent required a number of other dependencies in order to run, we would need to know the inner workings of a number of other classes just to test our LoginComponent. This results in Tight Coupling and our tests being very Brittle, i.e. likely to break easily. For example if the AuthService changed how it stored the token, from localStorage to cookies then the LoginComponent test would break since it would still be setting the token via localStorage.

      key points - this shows the benefits (easy) of this kind of testing and its disadvantages (coupled, easy to break if a service changes its implementation)

  2. Nov 2018
    1. Mocking localStorage is optional, but without mocking getComputedStyle your test won’t run, as Angular checks in which browser it executes. We need to fake it.

      key point

    1. Or inside the beforeEach() if you prefer to inject the service as part of your setup. beforeEach(() => { TestBed.configureTestingModule({ providers: [ValueService] }); service = TestBed.get(ValueService); });

      this corresponds with the option mentioned above - inject it inside a single test

  3. Oct 2018
  4. Sep 2018
    1. This is known as the entry file.

      Key point

    2. When we use ng new the Angular CLI creates a new workspace for us.In our Angular workspace we are going to have two projects:A library projectThis is the library of components and services that we want to provide. This is the code that we could publish to npm for example.An application projectThis will be a test harness for our library. Sometimes this application is used as documentation and example usage of the library.

      Good ideas about what to do with the needed 'application' that we are forced to create just to create the library.

    1. When we’ve generated the library (ng generate library tvmaze ) Angular CLI modified the tsconfig.json in the root of our project by adding tvmaze to the paths entry.

      Read - this is how to fake a local library to be imported by TS as if it was in node_modules

    2. Why is that useful? It enables such service to be tree-shaken (removed form the production bundle if not used)

      Very important note - useful!

  5. Aug 2018
    1. Then it gets the native element of the compiled HTML (the HTML rendered by the component).

      This explains what 'native element' is, at least in this case. Its the outcome HTML after the detectChanges()

    2. We use an async before each. The purpose of the async is to let all the possible asynchronous code to finish before continuing.

      Is this like putting your code in setTimeout() just to push it into the event loop task queue?...

    1. The CLI takes care of Jasmine and karma configuration for you.

      meaning, creating a new app using ng new will create the needed mentioned (below) config files

    1. The custom id is persistent. The extractor tool does not change it when the translatable text changes. Therefore, you do not need to update the translation. This approach makes maintenance easier

      key point! it allows English speaking site without worrying about translations at all, and keeping translation unit keys constant over time even if the English text is changing

    2. The Angular extraction tool preserves both the meaning and the description in the translation source file to facilitate contextually-specific translations, but only the combination of meaning and text message are used to generate the specific id of a translation. If you have two similar text messages with different meanings, they are extracted separately. If you have two similar text messages with different descriptions (not different meanings), then they are extracted only once

      important - this is how the 'keys' for the translation person are extracted - what determines the singularity of the translation item.

    3. You need to build and deploy a separate version of the app for each supported language

      key point!

    4. The CLI imports the locale data for you when you use the parameter --configuration with ng serve and ng build

      See sample i18n app (link in the beginning of this document). Basically, in package.json: "scripts": { "start": "ng serve", "start:fr": "ng serve --configuration=fr", "build": "ng build --prod", "build:fr": "ng build --configuration=production-fr",

    1. To define a class as a service in Angular, use the @Injectable() decorator to provide the metadata that allows Angular to inject it into a component as a dependency. Similarly, use the @Injectable() decorator to indicate that a component or other class (such as another service, a pipe, or an NgModule) has a dependency.

      This means that the 'injectable' decorator has two meanings and two usages. I think this wasn't so in the past.

  6. Jul 2017
    1. retire our default home page that is built with a Jade view, and instead use an Angular view

      use Angular view instead of Jade view

  7. Mar 2017
  8. Feb 2017
    1. how it uses zones

      Does anyone have an authoritative link for this concept of zones and how they work? It'd be much appreciated.

    2. In general, add providers to the root module so that the same instance of a service is available everywhere.

      So, from this I take it that once a Service is added to the root module, it can be used by any component of that module.

      What about the components imported, from sub-modules of the root one? Can their dependency needs be met, in similar fashion? For example, could a Component in another module (imported into the root one) just request a Service provided in the root module and have it properly injected from there, without anything else on the developer's part?

    3. you get a new instance of the service with each new instance of that component

      So, I take it that the Service instance will not be a singleton anymore? Whereas, if provided from the root module, it will?

  9. Jan 2017
    1. Component classes should be lean. They don't fetch data from the server, validate user input, or log directly to the console. They delegate such tasks to services.

      A really good point! Lean-ness is something to strive for.

    2. While a component is technically a directive, components are so distinctive and central to Angular applications that this architectural overview separates components from directives.

      As per the MVVM pattern, they sort of provide the support for the View. They are like the glue for the visual representation of a part of the application. A controller of sorts (but not quite one) of MVC.

    3. other metadata decorators

      A somewhat comprehensive list of the currently available class decorators and their roles can be found in the Official Angular Cheat Sheet.

  10. Dec 2016
  11. Aug 2016
    1. function(context, locals)

      context.locals as seen in a plunkr example

      var template =$parse( "libs[i]" ) ; this.libs=["ng" ," jquery", "bootstrap"] ; for(i= 0; i< this.libs.length; i++) {

      output = output + '

    2. ' + **template(this, {i: i}) **+ '
    3. '; this.parsedMsg = 'The project uses
        ' + output + '
      '; [ link here - http://plnkr.co/edit/IXo5QqKNfhCsnOGLzM4J?p=preview]


  • May 2016
    1. bower_components

      Ionic installs bower components (bower packages) into the project's lib folder:


      This behaviour is defined in the projects .bowerrc file, which looks like this:

        "directory": "www/lib"

      The project .bowerrc file may be found at the same level as the www folder.

      Note that if you install angular-chart this way, you don't need to install Chart.js separately; it is one of the dependencies that bower will install for you. Of course, you must include the script tag that references the Chart.js file as usual!

      Finally, if you want to link angular-chart.css you must follow the same procedure.

  • Mar 2016
    1. The basic argument here is that templates have an advantage because they are constrained compared to allowing component structure to be defined in arbitrary JS is valid.

  • Jan 2016
  • Aug 2015
    1. Angular 2 embraces web platform standards, so it puts the view of the component in the Shadow DOM of the element where it has been created. If your browser does not support Shadow Dom, Angular will emulate it on a par with native shadow DOM.

      At the time this was written I don't think vendors were anywhere near agreement on several major aspects of shadow DOM

  • Jun 2015