Skip to content
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

Option to return default content from eventContent #7110

Closed
1 task done
shridhar-tl opened this issue Dec 26, 2022 · 3 comments
Closed
1 task done

Option to return default content from eventContent #7110

shridhar-tl opened this issue Dec 26, 2022 · 3 comments

Comments

@shridhar-tl
Copy link

Reduced Test Case

N/A

Do you understand that if a reduced test case is not provided, we will intentionally delay triaging of your ticket?

  • I understand

Which connector are you using (React/Angular/etc)?

React

Bug Description

There are 2 issues in eventContent property when using React connector. This use to work fine with older version (v5.11.2) of product:

Issue 1: Earlier when using eventContent and when undefined is returned from the event, as a fallback FullCalendar use to take care of rendering the event. This was helpful to do custom rendering only in specific view mode.

For example: I want to customize the events of only "timeGridWeek" view mode, while I use all other view modes as well. In such cases, I was returning undefined from eventContent callback function and FC takes care of rendering those events.

But now, with latest version, if eventContent property is used, then developer need to take care of rendering events in all view modes. Returning undefined from eventContent callback renders empty event.

Issue 2:
const renderEC = viewMode === 'timeGridWeek' ? renderEventContent : undefined;
<FullCalendar ref={calRef} events={events} {...fcOptions} eventContent={renderEC} />

With the above code, if the view mode is switched after initially rendering, then new value for "eventContent" property is not accepted. What ever value is set while initializing the FC is retained internally and still the same callback is used.

@kamilchlebek
Copy link

I can confirm it's an issue that prevents us from upgrading to v6.
We also conditionally use custom & default renderer.

Would be great if we could switch back to default renderer somehow. Thank you!

@arshaw arshaw added this to the v6-api-brainstorm milestone Dec 27, 2022
@acerix acerix changed the title v6 broken - eventContent property not working as expected like in v5 Option to return default content from eventContent Dec 28, 2022
@slydor
Copy link

slydor commented Jan 4, 2023

Hi! I can also confirm this scenario, in v5 we override the rendering just for a special case, where we inject an icon in front of certain all-day events. For the rest, we also use the default rendering. We want to migrate to v6, but we might duplicate all the rendering logic, because we like the default rendering.

Suggestion: what if you would expose all the default renderers (renderInnerContent), so that we can call them? In that case, one could define the custom renderer like that:

import { EventContentArg, CustomContentGenerator, standartEventDefaultGenerator } from '@fullcalendar/core';
import { tableCellDefaultGenerator } from '@fullcalendar/daygrid';

const customContentGenerator: CustomContentGenerator<EventContentArg> = (args) => {
  if (args.event.extendedProps?.foo === 'bar') {
    return ({ html: "<i>nice!</i>" });
  }
  if (args.view.type === 'dayGridMonth') {
    return tableCellDefaultGenerator(args);
  }
  return standartEventDefaultGenerator(args);
}

@arshaw
Copy link
Member

arshaw commented Jan 31, 2023

I've implemented this in v6.1.0. Return true from the function to get the default rendering. Example here.

@slydor , I was thinking of an API similar to your idea, but it was impossible to get it to work with all connectors (vue/angular/react). It might be possible in the future if I extensively rework things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

5 participants