-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: log states via redux #421
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.
|
|
||
abstract class DiGraph { | ||
/** | ||
* Map of dependencies that can be overridden with mocks in test functions. | ||
*/ | ||
val overrides: MutableMap<String, Any> = mutableMapOf() | ||
val overrides = ConcurrentHashMap<String, Any>() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To ensure synchronization.
Build available to test |
📏 SDK Binary Size Comparison ReportNo changes detected in SDK binary size ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks promising. Given that no business logic has changed and testing results were positive, I'm happy shipping this to customers 👍🏻
is InAppMessagingAction.ProcessMessage -> state.copy(currentMessageBeingProcessed = action.message) | ||
is InAppMessagingAction.EmbedMessage -> state.copy(currentMessageBeingProcessed = null, currentModalMessage = null) | ||
is InAppMessagingAction.ClearUser -> state.copy(currentUser = null, messages = emptyList()) | ||
else -> state // For actions that don't change state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this saves some efforts, but it can lead to unexpected results as well for new states. Shouldn't we combine remaining states here instead of else block? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, this would change, when we start adding more actions, right now scope was just logging,
import org.reduxkotlin.applyMiddleware | ||
import org.reduxkotlin.threadsafe.createThreadSafeStore | ||
|
||
internal object InAppMessagingStore { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason for making this object. Why couldn't we leverage singleton from SDKComponent
for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are levering it from singleton, this was added as a precaution and since it doesn't need constructor.
GIST_TAG, | ||
"Found ${latestMessagesResponse.body()?.count()} messages for user" | ||
) | ||
inAppMessagingManager.dispatch(InAppMessagingAction.LogEvent("Found ${latestMessagesResponse.body()?.count()} messages for user")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we extract latestMessagesResponse.body()
to single variable and reuse in the line below?
GistSdk.removeListener(this) | ||
super.onPause() | ||
overridePendingTransition(0, 0) | ||
} | ||
|
||
override fun finish() { | ||
inAppMessagingManager.dispatch(InAppMessagingAction.LogEvent("GisModelActivity finish")) | ||
runOnUiThread { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we log on animations end too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some suggestions that apply to code in several areas so adding here.
- I think we can now remove
GIST_TAG
? - For logging the code looks to heavy at the moment
inAppMessagingManager.dispatch(InAppMessagingAction.LogEvent("message"))
Can we create some extension to reduce only for logging as it is used extensively? Something like this:
inAppMessagingManager.dispatchLogEvent("message")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For logging the code looks too heavy at the moment
This would go away, we would not need to log anymore, We are going to log each action and state afterward. This is just a manual action added to let the current logging come through.
closes: https://linear.app/customerio/issue/MBL-454/improve-debug-logs-for-in-app-android
Changes:
More details on the structure can be followed: https://www.notion.so/custio/InAppMessaging-revamp-A-brave-new-event-driven-world-7422938d647944999defc9cca9f113a3?pvs=4