Determine type of custom Feature fallback behavior

[sre-is-toby]

We've determined that there is custom behavior beyond just potential error messages that should be shown for a given Feature if enabled, disabled, or degraded; this could mean entirely hiding a feature versus showing some sort of status message.

We need to have some sort of state -> fallback behavioral mapping for a given Feature. This could be more complex, such as for [x] segment, do [y], but for now we should be able to support "Show an error on hover" versus "Hide the button entirely".

I'm not sure the best way of modelling this in a Feature db, but feel it should be mostly handled on the customer SDK side - however we should have some sort of property to if/else check on for the set status (fallback = hide | errorOnHover | errorpage?).

I'm assigning this to maggie as a customer expected behavior thing and something that heavily ties in to the SDK

[sre-is-toby]

@maggiepint I was thinking more about this and think this issue should move to stanza-js, if that makes the most sense to you? I think the browser sdk's DX/UX is really interesting generally, but I also this this woud make the most sense if the structure of the fallback behavior had some sort of struct to it. However, I was thinking about it - could Hub just return features that don't return back an error or behavior, rather than returning back a fuckton of Features that checking them will all result in "Yup, just render the thing."? That way the API has to return significantly less data & you'd get the delta by default on every call?

you could do, generally, for the Typescript Types some narrowing + structure of what's expected for DX. something like (I wanted to rename these as I wrote them out, but editing this in GH made that a PITA):

type FeatureFallbackType = 'Hide' | 'ErrorBanner' | 'Custom' | 'Tooltip';

type ErrorBannerFallbackBehavior = {
  fallbackType: 'ErrorBanner',
  errorMessage: string,
}

// will need some sort of componentRef: RefObject<HTMLDivElement> this should be set in code and not something over the wire as a weird div id pointer as that..doesn't make sense, but just to explain what I mean when I say tooltip - it's explicitly passing Stanza in their code the `ref` to the element they want to have the tooltip upon. This is different than feature state behavior since it's a ref to something internal to a customer component rather than to a wrapping behavior
// the structure here for an example would be something like either providing a `StanzaTooltip` helper type that would handle the `ref` setting by explicitly wrapping a provided react component, or telling the consumer themselves to assign the `ref` on creation of their component and use `createRef` and `forwardRef` or something
type TooltipFallbackBehavior = {
  fallbackType: 'Tooltip',
  errorMessage: string
} 

type CustomFallbackBehavior = { 
   fallbackType: `Custom` // this type would be where the developer explicitly takes responsibility for the rendering if/else behavior, but the check they'd be making?
}

type FeatureStateFallbackBehavior = {
  fallbackType: `Hide`
} | ErrorBannerFallbackBehavior | TooltipFallbackBehavior | CustomFallbackBehavior; // discriminated type union for conditional properties based on the type of something :)

// using `state` as then the discriminator between the type of object returned from the API. this would be helpful both internally but externally as types for the browser library for folk / what is exported there for stanza customers to use in their app
type FeatureState = { featureName: string; state: Healthy} | { featureName: string; state: Degraded; fallback: FeatureStateFallbackBehavior};

[sre-is-toby]

Wow, that got much more detailed than I was thinking, but question remains @maggiepint - I'm moving this to stanza-js.

askforgivenessnotpermissionIguess?

[sre-is-laura]

There is also the idea of Features that wrap something that is recurring behavior, i.e. content that's periodically refreshed or a websocket or something. Do we want to support degrading those for already-rendered pages?