ADR 1: Define how to better pass parameters to native side

[lenoirzamboni]

Architecture Decision Review - ADR

We need to discuss a better way to pass parameters to the native side while using the API methods. The current way is not so didactic, and this can cause confusion and even errors while using the library.

We have two options:

1. Modify the current native methods to accept a dictionary as param;

Pros:

• No need to create interfaces;
• No necessary changes to index.js ;
• No need to export types using index.d.ts.

Cons:

• While we still can create interfaces and make it available to the users, we cannot force the usage of it, which can still lead to errors, for example, using wrong key names.

Example of this idea:

import { NativeModules } from 'react-native'

... 

const salesforceChat = NativeModules.RNSalesforceChat
salesforceChat.createPreChatData({
  agentLabel: "Account ID",
  value: "b1174ff9-7b5b-4c2a",
  isDisplayedToAgent: false,
}))

 

2. Create and export methods on our index.js and future index.d.ts. These methods would accept objects defined by interfaces that we can also create and export to the user.

Pros:

• We can force the usage of interfaces, meaning no wrong key names;
• We can stop exporting the native module directly, and export only the functions we want;
• Easier import and usage;
• No need to change the native code.

Cons:

• With every API change (on the native side), we would need to take extra care to also update the index files.

Example of this idea:

// PreChatData.ts

export interface PreChatData {
  agentLabel: string
  value: string | undefined
  isDisplayedToAgent: boolean
}

import { createPreChatData } from '@loadsmart/rn-salesforce-chat'

...

createPreChatData({
  agentLabel: "Account ID",
  value: "b1174ff9-7b5b-4c2a",
  isDisplayedToAgent: false,
})

[lenoirzamboni]

@barbosa @pedrohperalta can you take a look at this? Feel free to comment on it and bring other ideas and suggestions.

[barbosa]

@lenoirzamboni good ADR 🙂

Which of the two options are you more inclined to use? And why?

[lenoirzamboni]

@lenoirzamboni good ADR 🙂

Which of the two options are you more inclined to use? And why?

@barbosa I'm inclined to use the second option. I believe it's a more common approach, easier to understand and use.

[barbosa]

Great!

I also like option 2.

Option 1 works fine but I believe it exposes to much the internal implementation. Although we're not limited by that, I'd prefer option 2's ability to have clear and well-defined methods/API.

The con mentioned in option 2 doesn't worry me that much since I think it's implicit that every time we change something on the native side, we'd need to make sure the external contract won't break.

[lenoirzamboni]

@barbosa All right! I'll work on these changes then!