-
Notifications
You must be signed in to change notification settings - Fork 105
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
[#163591901,#163591918,#163591935] Messages Inbox/Deadlines/Archive Tabs (v2) #823
Conversation
Affected stories
Generated by 🚫 dangerJS |
Codecov Report
@@ Coverage Diff @@
## master #823 +/- ##
==========================================
- Coverage 46.69% 46.11% -0.58%
==========================================
Files 178 187 +9
Lines 3602 3801 +199
Branches 703 727 +24
==========================================
+ Hits 1682 1753 +71
- Misses 1918 2046 +128
Partials 2 2 |
44c436e
to
c054f16
Compare
selectedMessageIds, | ||
toggleMessageSelection: this.toggleMessageSelection, | ||
resetSelection: this.resetSelection | ||
} as P; |
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.
is the cast really needed?
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.
Sadly yes :(
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 idea why?
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.
From my research it is related to microsoft/TypeScript#28938
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.
have you tried this option - it looks safer than casting the merged props
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.
Yes i remeber that i also tested that solution and had no problem. Going to change.
|
||
type State = { | ||
isSelectionModeEnabled: boolean; | ||
selectedMessageIds: Map<string, true>; |
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.
you should probably use an Option<Set<string>>
here
|
||
private resetSelection = () => { | ||
this.setState({ | ||
isSelectionModeEnabled: false, |
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.
if you use an Option<Set<string>>
you can just set selectedMessageIds
to none
to encode both the fact that selection mode is off and no messages are selected
selectedMessageIds.get(id) | ||
? selectedMessageIds.delete(id) | ||
: selectedMessageIds.set(id, true); | ||
return { isSelectionModeEnabled: true, selectedMessageIds }; |
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.
see next comment
return <WrappedComponent {...mergedProps} />; | ||
} | ||
|
||
private toggleMessageSelection = (id: string) => { |
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.
comment this function
ids.map(messageId => messageStateById[messageId]).filter(isDefined) | ||
) | ||
), | ||
lastUpdate: Date.now() |
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'm not sure why we need this, shouldn't createSelector
memoize the result making it possible ti swallow compare it with the previous value?
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.
check out https://github.com/reduxjs/reselect#createselectorinputselectors--inputselectors-resultfunc + defaultMemoize
and createSelectorCreator
|
||
private handleOnPressItem = (id: string) => { | ||
if (this.props.isSelectionModeEnabled) { | ||
this.handleOnLongPressItem(id); |
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.
shouldn't this be handleOnPressItem
?
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 to add a comment here. If we are in selection mode a "press" need act like the "longPress" (select the item).
private setMessagesArchivedState = ( | ||
ids: ReadonlyArray<string>, | ||
archived: boolean | ||
) => this.props.dispatch(setMessagesArchivedState(ids, archived)); |
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.
use a map dispatch to props here
@@ -44,9 +44,16 @@ export const setMessageReadState = createAction( | |||
resolve => (id: string, read: boolean) => resolve({ id, read }, { id, read }) | |||
); | |||
|
|||
export const setMessagesArchivedState = createAction( | |||
"MESSAGES_SET_ARCHIVED", | |||
resolve => (ids: ReadonlyArray<string>, archived: boolean) => |
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.
instead of a boolean
, I would encode the actual states with and ADT, e.g. :
resolve => (ids: ReadonlyArray<string>, archived: boolean) => | |
resolve => (ids: ReadonlyArray<string>, state: "VISIBLE" | "ARCHIVED") => |
much clearer and less error prone than a boolean
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 a diferrent opinion about this for a couple of reason:
- "visibile" is not an alternative of "archived". i mean what is visible in a screen can be not visibile in onother. The MessageSearchResult component (coming) display both "visible" and "archived" messages (the same is true for the Deadlines)
- a boolean as representation of the archived state is more like the one that in the future will be implemented server side (i mean the message object returned by the api will have a archived boolean property)
- if tomorrow we want to add a new state like "starred" seem unreal to have "visible" | "archived" | "starred"
What you think?
import { MessageContent } from "../../definitions/backend/MessageContent"; | ||
import { MessageWithContentPO } from "./MessageWithContentPO"; | ||
|
||
type MessageContentWithDueDate = MessageContent & { |
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.
you can use a utility method called requireProperty
that we used for pagopa - see an example here https://github.com/teamdigitale/italia-app/blob/master/ts/types/pagopa.ts#L52
locales/en/index.yml
Outdated
@@ -459,6 +459,8 @@ messages: | |||
fetchCalendars: Error fetching calendars | |||
unknownSender: Unknown sender | |||
noContent: Content not available | |||
agenda: | |||
sectionDate: "dddd D MMMM" |
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.
this date format is not specific of the agenda view, it should be under the global namespace
A replacement for #821 with only changes strictly needed and better architecture.