Skip to content

EMBR-5086 updates to redux instrumentation#22

Merged
jpmunz merged 14 commits intofacosta/instrumentation-react-native-reduxfrom
jpmunz/EMBR-5086-update-actions-package
Jan 20, 2025
Merged

EMBR-5086 updates to redux instrumentation#22
jpmunz merged 14 commits intofacosta/instrumentation-react-native-reduxfrom
jpmunz/EMBR-5086-update-actions-package

Conversation

@jpmunz
Copy link

@jpmunz jpmunz commented Jan 15, 2025

  • adding outcomes
  • switching attribute customization to a function
  • adding a test for when there's another middleware setup

@notion-workspace
Copy link

@jpmunz jpmunz requested a review from facostaembrace January 15, 2025 23:28
const provider = createInstanceProvider();

// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@facostaembrace I noticed a few of these @ts-ignore lines are they all needed? My IDE was also complaining about this typing from line 44: middleware(undefined, { debug: false })(store);

const result = next(action);
return next => {
return a => {
const action = a as Action;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the only way I found to get around the typescript error was to remove the typing from the functions here and then try and cast the unknown value back to an Action, given the way Redux types its middleware I'm not sure that there would be a better way since next, action, are all hardcoded as "unknown":

interface Middleware<_DispatchExt = {}, // TODO: see if this can be used in type definition somehow (can't be removed, as is used to get final dispatch type)
S = any, D extends Dispatch = Dispatch> {
    (api: MiddlewareAPI<D, S>): (next: (action: unknown) => unknown) => (action: unknown) => unknown;
}

const {
debug,
name,
attributeTransform = defaultAttributeTransform,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a particular reason why we are switching to a function? if so, should we apply the same to the otel navigation instrumentation library?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this gave more flexibility to overriding the behaviour when we use it in the Embrace SDK here: https://github.com/embrace-io/embrace-react-native-sdk/blob/c6861108b07fa129251dc8b426a740f8ebdf31da/packages/react-native-redux/src/index.ts#L40

e.g. our backend expects payload_size so I was able to transform the existing payload attribute rather than only being able to add a static value

for the navigation case we're able to get what we need with just a static attribute for now but ya it probably does make sense to accept a function there as well to allow more options in the future

@facostaembrace
Copy link

it seems like the update of @reduxjs/toolkit@2.5.0 is missed in the package-lock.json (reason why CI's are failing)

@jpmunz
Copy link
Author

jpmunz commented Jan 20, 2025

it seems like the update of @reduxjs/toolkit@2.5.0 is missed in the package-lock.json (reason why CI's are failing)

I had skipped updating the package lock before, let me update and see if it addresses things

@jpmunz
Copy link
Author

jpmunz commented Jan 20, 2025

it seems like the update of @reduxjs/toolkit@2.5.0 is missed in the package-lock.json (reason why CI's are failing)

I had skipped updating the package lock before, let me update and see if it addresses things

The various "Unit Tests" ones still fail with Service container mssql failed

I'll take a look at the peer-api-check one as that failure seems related to the otel api version in the package

@jpmunz jpmunz merged commit 51a0f5a into facosta/instrumentation-react-native-redux Jan 20, 2025
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants