What Is ViewEncapsulation in Angular?

Reference Reference

• ViewEncapsulation.None - No DOM, the style is not scoped to the component.
• ViewEncapsulation.Emulated - Default option - Angular will not create a Shadow DOM for the component, the style will be scoped to the component. It has the _ngcontent-sds-c17 attribute to ensure that it’s encapsulated.
• ViewEncapsulation.ShadowDom - Angular renders the component inside the shadow root element.
• Shadow DOM is part of the Web components standard - this encapsulation allows us to hide DOM logic behind elements and scope the styles to an element.
  • Angular uses Emulated, because back in the day, most browsers were not supporting Shadow DOM.
  • Important difference between Emulated and Shadow DOM: The global styles wouldn’t work in the Shadow DOM. But, you can apply styles to projected content.

Angular Extended Diagnostics

Reference

• Can add like this: ` { “compilerOptions”: { “strictNullChecks”: true, “angularCompilerOptions”: { “strictTemplates”: true, “extendedDiagnostics”: { “checks”: { “nullishCoalescingNotNullable”: “error” }, “defaultCategory”: “error” } } } `

Test your components with Angular Material’s component harnesses!

Reference

How to write component harnesses in Angular

Reference

Improve SPA performance by splitting your Angular libraries in multiple chunks

Reference

• ng-packagr allows you to use an ng-package.json in combination with a public-api which will end up as an entry point to your application.
  • index.ts points out public_api in package.json.
  • The public API contains the module and component.
• Not sure about this. I think we should just use Standalone components anyway.

Angular Regime Series: Tree Shaking Technique

Reference

• Bundlers rely on minifiers like uglify and reduce the whole application code into a single bundle file. For Angular, the whole tree shaking technique is built-in.

ES5-ES6
import X from "y";
export Z;

CommonJS
const X = require("y")
module.exports = Z;

• Angular can track all components in a module, but how can Angular track the dependency services included in the provider’s Array?
• Tree-shakeable providers: TSP will register the service to the root injector which makes it available as a Singleton service.

Angular Regime Series: Difference Between Promise and Observable

Reference

• Observable can cancel operations. Promises can only return a response, either resolved or rejected. Promises can’t cancel the call. Observable returns a subscription object, which can be used to cancel it. There are some promise libraries that support cancellation, but the ES6 promise doesn’t so far.
• Observable is lazy - need to subscribe to execute it.
• Observables can be async and can be sync. Sync:

firstObsr$.subscribe({
  next: console.log,
  complete: () =>{
      console.log('End of first observable')
      secondObsr$.subscribe({
        next: console.log,
        complete: () => {
          console.log('End of second observable')
        }
      })
     }
});

• Also, can do concatMap:

const map = from([
  firstCall,
  secondCall,
  thirdCall,
  fourthCall,
  fifthCall,
]).pipe(
    concatMap(x => x)
  )
  .subscribe(x => console.log(x))

• Emitting multiple values.

Frontend system design interviews - the definitive guide

Reference

• Problem solving ability: Knowing what question to ask.
• Technical proficiency and knowledge: know what the strengths and weaknesses of specific solutions.
• Operational awareness:
  • What can go wrong?
  • What are the specific failure modes?
  • UX when things fail and when back-end is slow?
  • How will we know if what we built is wrong, successful?
  • How will we handle 100x more data on this screen or component?
• Fitting more stuff into the screen:
  • Virtualized list, paginated tables, tabs, scroll view, drawer, master-detail, full page navigation, modal, combo box, collapsible sections/accordion.
• Avoid:
  • Jumping straight into solution mode.
  • Not being collaborative.
  • Don’t BS.
  • Not playing to your strengths.
• Creating design artifacts on the whiteboard as you move through each interview section will help you build momentum and confidence throughout the interview.
• High-level design questions:
  • Front-end of Slack? Front-end of photo-sharing application like Instagram? Designing a rich text editor?
  • Low-level design questions: Infinite scrolling? Combo-box/type-ahead component? Loading progress bar for an API?
• Gathering requirements:
  • Expected users of the system - is it internal or external?
  • Accessibility, mobile responsiveness, low power CPU devices.
  • Top use cases?
  • Build pipeline?
• Approaches to testing, observability, analytics, error monitoring, resiliency through graceful degradation.
• High-level architecture design
  • Wire frame, data entities, break down of wire-frame, higher level APIs, user and system initiated events.
  • Other considerations: Security, accessibility, performance, delivery, testability, resiliency, observability.
  • Maintainer’s viewpoint - retries, error states, loading skeletons. Then, how can the API be adapted over time?
• Optimizations?
  • Reproducing reliably.
  • Narrow down.

The Elements of UI Engineering

Reference

• Consistency - if you like and unlike something, you want that status change/state to be consistent.
• Responsiveness - for discrete actions like clicks, any <100ms delay is fast. If the action is longer, show a visual indicator.
• Latency - And action depending on new data, code, or assets is potentially asynchronous and needs to handle the loading case. Also try not to have “jumpy” layout.
• Navigation - switching between /profile/likes and /profile/follows tabs on a profile screen shouldn’t clear a search input outside the tabbed view. Even navigating to another screen.
• Stale - Local cache + when to invalidate it?
• Entropy.
• Priority - what is on top of what?
• Accessibility - we need to make the apps not horrible to people with disabilities- - disability affects 1 in 5 people.
• Translations/internationalization.
• Delivery - which payload/lazy-loading.
• Resilience - what happens when the code crashes?
• Abstraction - how do we reuse, fork, and join parts of our code, and work on it collectively? We want to define clear boundaries between the pieces familiar to different people, and avoid making often-changing logic too rigid. How do we create abstractions that hide implementation details of a particular UI part? How do we avoid re-introducing the same problems that we just solved as our app grows?

7 Principles of Rich Web Applications

Reference -

• Pre-rendered/server-rendered - minimising the number of round trips you make to display information on the page is essential to great UX and responsiveness.
• Large scripts take a lot longer to download than it seems. Pre-rendering the content above the fold is a viable option.
• Act immediately on user input - you can optimistically change something.
• JS inline-as-you-type suggestions - pioneered in 2004. Then 2010, instant search by skipping the page refresh.
  • Situations where immediacy is bad - payment form or logout link. The spinners can even be deferred/delayed.
• React to data changes/log out on different tabs.
• Don’t break history, enhance it. Ex: ignoring scrolling memory.
• Negative latency - predicting things?