{ "attributes": { "id": "scroll-targeting", "linkText": "Scroll Targets", "title": "Automatic Scrolling and Click To Copy Headers", "group": "Architecture" }, "body": "

Fountainhead has different automatic scrolling to header and property ids for Hash\nLocation consumers and History Location consumers. The goal of this is to offer very\nclean URLs for consumers using history location routing, while still supporting targeted\nscrolling for consumers using hash location routing. History routing consumers will\ngenerate URLs with fragment ids. Hash routing consumers will generate URLs with id\nquery params:

\n

History Location Routing:
\nyour-docs.com/guides/your-guide#header-id
\nHash Location Routing:
\nyour-docs.com/#/guides/your-guide?id=header-id

\n{{#fountainhead-header tagName=\"h2\" elementId=\"feature-overview\"}}Feature Overview{{/fountainhead-header}}\n

If you need to make an update or log a bug against the feature this overview will\nprovide background information on how the overall flow executes.

\n
    \n
  1. Addon index.js reads consuming application's locationType in addon config\nhook. The locationType is passed into every call to generate documentation data.\nIn data generation, if the locationType is hash, the flag hashRouting is\nset to true and added to the documentation meta. (History routing is the\ndefault routing expected. hashRouting is only set as an override)
    2. \n
  2. Addon begins tracking the location hash in order to pass the hash down as a data\nelement. Routes /api and /guides activate hook trigger the fountainhead\nservice to set an event listener for the hashchange event. This event fires\nanytime an in page url with a hash fragment is clicked. All routes will reset the\ntracked fragment id and then update it after the url changes (Required due to\nroute changes not firing the hashChange event).
    3. \n
  3. Routes will reset the page scroll to the top on every transition. This ensures\nthat if the page is scrolled, and the new route doesn't have a scroll target, the\npage is correctly scrolled to the top.
    4. \n
  4. Page templates pass either the tracked hash fragment or the controller id query\nparam to page components depending on the consuming routing type.
    5. \n
  5. Any change in the model or passed scroll target will trigger the page's\ndidReceiveAttrs hook, which is used to scroll to the passed target, or scroll to\ntop of page if no target is present.
    6. \n
  6. Headers and property links are wrapped in either an anchor with the href set to a\nfragment id for history location consumers or a link-to with the id query param\nfor hash location users.
    7. \n
\n{{#fountainhead-header tagName=\"h2\" elementId=\"feature-overview-ii\"}}Feature Overview II{{/fountainhead-header}}\n
    \n
  1. Addon checks if consumer is using Hash or History location, updates Fountainhead's\ndocumentation meta with flag.
    2. \n
  2. IF HASH => Use query params, and everything will Just Work™. Router, link-tos and\ncontrollers automatically track id query param. Passed down into page components\nwe can use didReceiveAttrs hook to execute scrolling.
    3. \n
  3. IF HISTORY => Hash has to be tracked:\n\n
    4. \n
  4. On route activation, send trackHash, creates new listener for hash change AND\nsets current hash if one has been set (this is how page reload still triggers a\na scroll).
    5. \n
  5. Clicking an anchor with fragment ONLY will fire a hash change event, but clicking\na link-to to a different route OR clicking browser back button will NOT fire a\nhash change event.
    6. \n
  6. For route changes:\n\n
    7. \n
\n", "frontmatter": "id: scroll-targeting\nlinkText: Scroll Targets\ntitle: Automatic Scrolling and Click To Copy Headers\ngroup: Architecture", "id": "scroll-targeting", "type": "guides" }