-
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
Select/reset button for events #55
Conversation
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
1 similar comment
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
Only one regression I found: the agenda section has missing data. I've just fixed this |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
…reasing line spacing
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
I'm out this morning, but I'll get to this today, thanks Oliver! Would normally avoid global state/rerenders for performance and complexity, but seems fine here (even faster than the FC API anecdotally) and I don't see the state growing too much. |
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.
Not sure how I feel about the state handling, but it works and the rest is great so I'm happy.
Co-authored-by: Tom Plant <[email protected]>
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
1 similar comment
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
Re: state handling, the reason I moved everything into App was because a lot of stuff didn't make sense inside Toolbar, eg which events are selected, and I needed a way to propagate that info into the Calendar. The state handling is not ideal, I agree, I only did precisely enough refactoring to enable me to pass the state where it was needed, but didn't clean it up afterwards. Virtually all of the state handling code is the same or very similar, it's just been moved and is all passed down |
All good, originally I stored all user input in the toolbar (and using the calendar ref just to display), but that fell apart when the calendar itself took input. Glad we're on the same page, not ideal as-is but a big improvement on what I had, and enough to release to users. |
Nice! TIL that exists |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://yellow-cliff-008e54a00-55.eastasia.azurestaticapps.net |
Thinking about the state management, the main reason it's ugly is because |
ahhhhh, I thought FC was declarative? never tested cause I was attempting to wrangle the API, which was a poor choice in hindsight. https://fullcalendar.io/docs/initialEvents seems to imply the default is declarative, with an imperative escape hatch. (edit, swapped imperative/declarative by accident lol) |
Yeah what I'm proposing is a wrapper that makes a prop like Edit: see your edit now, gotcha. |
Yeah, makes sense but I think the default events prop (eg https://fullcalendar.io/docs/events-array) is declarative, and initialEvents is imperative for those that want it |
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.
LGTM ❤
No description provided.