DOM Integration

the appstory react web sdk integrates with your application through the browser dom by assigning stable identifiers to important html elements, the sdk can discover, capture, and target those elements for features such as screen capture, tooltips, and widget placement—without requiring changes to your existing react component structure this applies to any react based application, including those built with vite, next js, remix, or create react app data as id the primary identifier used by appstorys is the data as id attribute—a plain html attribute you add directly in your markup \<div data as id="hero section"> welcome \</h1> \</div> \<button data as id="buy button" type="button"> buy now \</button> give the appstorys team the identifier string so they can configure a campaign against it—the value is just a string you choose; it carries no other meaning keep identifiers unique duplicate identifiers create ambiguous targeting, since the sdk's lookup returns only the first matching element use a unique identifier per screen for every element you plan to target target resolution order whether the sdk is matching a tooltip target, a widget host, or an element for screen capture, it checks for a match in the same order priority selector example 1 data as id \[data as id="top"] 2 data id \[data id="top"] 3 html id #top 4 css class top the first match wins data as id is recommended for new elements, since it's checked first and works reliably across tooltips, widgets, and screen captures alike tooltip targeting tooltip campaigns (single step or multi step) attach to a specific dom element using the resolution order above targeting is continuous, not a one time check if the target element isn't in the page yet—for example, it's inside a closed dropdown, an unopened submenu, or a list rendered after an api call resolves—the sdk keeps watching the page and attaches the tooltip the moment the element appears no manual rescan is needed if the target never appears, that tooltip step is simply not shown the dimmed backdrop behind an active tooltip is visual only—it does not block clicks, and page scrolling is never locked while a tooltip is showing for elements generated from dynamic data (menus, dropdowns, api driven lists), derive the identifier from the item's own stable data—a slug of its label or its backend id—never from array index or render position, so the same logical item keeps the same identifier across re renders {/ static items /} \<a data as id="nav dashboard" href="/dashboard">dashboard\</a> {/ items generated from an api response /} {menuitems map((item) => { const slug = item label tolowercase() replace(/\[^a z0 9]+/g, ' '); return ( \<a key={item id} href={item path} data as id={`nav ${slug}`}> {item label} \</a> ); })} widget hosts widget campaigns can be rendered into specific locations within your page by creating placeholder host elements mount widget components import { widget } from '@appstorys/react web'; x{widgetscomponent ? ( \<widgetscomponent position="amanhasnainy" leftpadding={60} rightpadding={60} /> ) null} if a matching host element exists, the widget renders inside it using a react portal if no matching host is found, it renders inline where it \<widgetscomponent /> is mounted—your application continues to function normally either way for an app with only one widget, you can skip host elements and mount \<widgetscomponent /> directly where you want it to appear if no campaign has been assigned to a given placeholder in the dashboard, that simply renders nothing widget placeholders are entirely optional—if your application doesn't use widget campaigns, you can skip this section and simply track the screen; no host elements or \<widget /> components are required screen capture when enabled for your account, the sdk captures the current screen's layout and uploads it to the appstorys dashboard, so the appstorys team can visually pick elements to target using data as id improves screen capture by labeling elements with meaningful identifiers and keeping dashboard mappings stable across releases verifying your integration the sdk exposes a console helper that visually outlines every element on the current page carrying a recognized targeting attribute window\ appstorysshowwidgetelements() run this in your browser's developer console after integrating to confirm your elements are wired up correctly before asking the appstorys team to configure a campaign against them