-
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
Additional Stores #215
Additional Stores #215
Conversation
- CalendarStore will only pull if the `isInit` value is false. - CalendarStore cache is busted on user action. - AppointmentStore will always pull if requested (Due to some impl concerns.)
const hasZoomAccountConnected = computed(() => (externalConnections.value?.zoom?.length ?? []) > 0); | ||
const zoomAccountName = computed(() => (externalConnections.value?.zoom[0].name ?? null)); | ||
const hasZoomAccountConnected = computed(() => (externalConnectionsStore.zoom.length) > 0); | ||
const zoomAccountName = computed(() => (externalConnectionsStore.zoom[0].name ?? null)); |
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.
Since we only allow one zoom connection, any objection to the zoom getter just grabbing the first item?
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.
No, I think this is fine. Maybe adding a comment indication that we currently only handle one zoom connection would make things clearer here. Is externalConnectionsStore.zoom[0].name ?? null
sufficient or do we need another ?
before the .name
, in case no connection is defined?
// get remote calendar data for current year | ||
const calendarEvents = ref([]); | ||
const getRemoteEvents = async (from, to) => { | ||
calendarEvents.value = []; | ||
await Promise.all(props.calendars.map(async (calendar) => { | ||
await Promise.all(calendarStore.connectedCalendars.map(async (calendar) => { |
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 can potentially move this to the calendar store, since schedule probably uses similar code but I'm also good with this living here. Any thoughts?
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 sounds reasonable to get calendar events over the calendar store 👍🏻
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.
Again a lot of work improving our code base. Thank you Melissa!
frontend/src/App.vue
Outdated
import { | ||
inject, provide, onMounted, computed, | ||
} from 'vue'; |
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.
Do you use a line length limitation < 120? Just wondering about the line breaks here.
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 need to fix this up as my ide is at odds with eslint. 😵
const hasZoomAccountConnected = computed(() => (externalConnections.value?.zoom?.length ?? []) > 0); | ||
const zoomAccountName = computed(() => (externalConnections.value?.zoom[0].name ?? null)); | ||
const hasZoomAccountConnected = computed(() => (externalConnectionsStore.zoom.length) > 0); | ||
const zoomAccountName = computed(() => (externalConnectionsStore.zoom[0].name ?? null)); |
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.
No, I think this is fine. Maybe adding a comment indication that we currently only handle one zoom connection would make things clearer here. Is externalConnectionsStore.zoom[0].name ?? null
sufficient or do we need another ?
before the .name
, in case no connection is defined?
a.calendar_title = calendarsById[a.calendar_id]?.title; | ||
a.calendar_color = calendarsById[a.calendar_id]?.color; |
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.
At some point we can improve this by appending the corresponding calendar object to the appointment.
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.
And done!
// get remote calendar data for current year | ||
const calendarEvents = ref([]); | ||
const getRemoteEvents = async (from, to) => { | ||
calendarEvents.value = []; | ||
await Promise.all(props.calendars.map(async (calendar) => { | ||
await Promise.all(calendarStore.connectedCalendars.map(async (calendar) => { |
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 sounds reasonable to get calendar events over the calendar store 👍🏻
…with appointments. We don't need to merge the calendar data anymore since we do on the backend, and we now call the db refresh function on all pages that may require appointments. This prevents doubling requests if you start on the Calendars page for example.
I have added calendar_title and calendar_color to /me/appointments and removed the calendar part of that merge function. I've also removed the initial call to get calendars and appointments since we already fetch that data where we need it. This prevents double requests being sent if you start appointments on a page that also request appointment and calendars 😄 |
Resolves #141
I've added some new stores:
These are all per session, so they're not cached in localstorage and will disappear if you refresh the browser. But they'll persist through router navigation.
For what gets access to a store vs a prop: Views should access stores, if a component can potentially take in a generic list of data then it should use a prop, otherwise it can use a store. (Generally components should take in props though.) I'm up for discussion on this though 😄
With #198 this should get rid of any remaining annoying page flashing while requests are happening.