-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: add select for sorting flow list #4137
base: main
Are you sure you want to change the base?
Conversation
refine component and sort style style refinement on layout add status to getFlows refine type use on sort keys
f235e5b
to
73f0b7c
Compare
@@ -390,6 +400,13 @@ export const editorStore: StateCreator< | |||
lastName: last_name | |||
} | |||
} | |||
publishedFlows: published_flows( | |||
order_by: { created_at: desc } | |||
limit: 1 |
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.
Seen this was only used by the Team page, so though it felt better to expand this initial query
}) => { | ||
const [sortBy, setSortBy] = useState<SortObject>(sortArray[0]); | ||
const [sortDirection, setSortDirection] = useState<SortDirection>("asc"); | ||
useEffect(() => { |
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.
Went with a useEffect here to provide stability for adding more sorting types, would be interested to know if there's cleaner techniques
if (!b[sortKey][0]) return -1; | ||
|
||
const aValue = a[sortKey][0][nestedKey]; | ||
const bValue = b[sortKey][0][nestedKey]; |
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.
Although this possibly looks overly complicated, it allowed me to use the type safety to build the sortArray
while not having to map sorting names to data fields with ternaries or conditional statements.
I iterated this a bit and found that the extra code came a lot from the nested keys in the flows
array, but the extra lines always provided better maintainability for adding or removing sorting criteria while remaining aligned with what data is provided to us from the getFlows
query
What does this PR do?
Working towards this EPIC: https://trello.com/c/7av8lsVr/3160-epic-as-an-editor-i-want-to-have-a-way-to-organise-my-flows-so-that-i-can-easily-find-what-im-looking-for
I created the outline logic and component for sorting the list of flows. My hope for this was to provide a maintainable, scalable component for sorting the list of flows on the Team page using keys we receive from
getFlows()
contained within theFlowSummary
interface.Right now it covers: Name, Last Published, Status, and Last Updated. I added an ascending or descending toggle as well.
See this as just the building blocks of the sort component I can add into Ian's work on the new Team page and filter.
Still to-do: