All quizzesHard
Functional Guards — Series 3
Preview — 3 of 10 questions
Which route-derived values does withComponentInputBinding() actually wire up as component inputs?
javascript
provideRouter(routes, withComponentInputBinding());APath parameters, query parameters, and resolved/static route data are all automatically bound to any component input whose name matches — id picks up the :id path segment, and extra picks up whatever extraResolver returned, with no manual ActivatedRoute wiring needed for either. Only values with no matching input name on the component are left unbound
BOnly path parameters — resolved data and query parameters still require manual subscription to ActivatedRoute
CIt only binds values that are explicitly listed in a separate inputsMap configuration object passed alongside withComponentInputBinding()
DIt binds every route value into a single input named routeData, requiring the component to destructure it manually
How do you navigate specifically the popup outlet to a compose route, without disturbing whatever's currently shown in the primary (unnamed) outlet?
javascript
<router-outlet></router-outlet>
<router-outlet name="popup"></router-outlet>Athis.router.navigate(['/compose']) — outlet targeting happens automatically based on which route matches
Bthis.router.navigate(['popup:compose']) — outlet name and path are combined into a single string segment
Cthis.router.navigate([{ outlets: { popup: ['compose'] } }]) — an "outlets" command object explicitly maps each named outlet to its own commands array; outlets not mentioned in the object (like the primary one here) are left completely untouched by this navigation
DNamed outlets can only be controlled by directly setting <router-outlet name="popup" [route]="..."> as a template binding, never imperatively
A user scrolls halfway down /articles/5, then clicks a link to /articles/6. Whats the scroll position on the new page, versus what happens if they then click the browsers Back button?
javascript
provideRouter(routes, withInMemoryScrolling({ scrollPositionRestoration: 'enabled' }));ABoth cases restore the previous scroll position — 'enabled' always remembers and restores scroll position for every navigation, forward or back
BNeither case restores anything — 'enabled' only affects scroll behavior for anchor-fragment (#section) navigation, not plain page-to-page navigation
CNavigating forward to /articles/6 resets scroll to the top (a genuinely new page, with no prior scroll history for it) — clicking Back to return to /articles/5 restores the scroll position it had when the user left it, since browser back/forward navigation is specifically what 'enabled' restoration targets, distinct from a fresh forward navigation
DScroll position is preserved forward but reset on Back, the reverse of typical browser behavior
Sign up free to play
Answer all 10 questions (7 more), see explanations for every answer, and track your score.