Next major version: 6.0, incl. support for Vaadin 23 / 24

Question

Next major version: 6.0, incl. support for Vaadin 23 / 24

Closed this issue a year ago · 17 comments

Answer 1 · 2022-11-14T17:33:18.000Z

Check the branch 4.2.0_dev d57d684

Answer 2 · 2022-11-18T12:18:52.000Z

Instead of recopy all the CSS from the original FC repo I just merger the changes they made comparing the files.

Answer 3 · 2022-12-19T08:13:50.000Z

Since v6 is now out, it might be outdated :/

Going to check v6 and if it might be a good point to translate the addon to Lit and V23

Answer 4 · 2022-12-19T15:37:10.000Z

Started to start a TS / LitElement conversion together with v6.

One big change with FC6 is, that it does not require to import styles anymore. But of course, they do not had have shadow dom in mind (again), which mean, that the fc will now be slotted and thus styles will be applied like in the light dom. I am not yet sure, if I like this change or not. It will make styling easier, but also has the good old bleeding in of other styles. Currently, there is a lumo styling, that auto applies the "disabled text" color to all links (aka all normal text and numbers in the FC). :/

The typescript conversion is not yet done, it is just the minimal necessary stuff to make it compilable (so a lot of "any" usage and some ts-ignore).

LitElement is ok so far, no major impacts or downsides.

Removed for now the client side support of in memory. Target is, that the client side will always use fetching / lazy loading and only the server side provides in memory support (similar to Vaadin Grid, where the data provider might be in memory, but the grid will always fetch only the needed rows). But that is not yet implemented.

All in all the basic stuff seem to work, so I hope, that it is a good chance to take some time for cleaning up old stuff. But maybe it will be better to wait for some improvements in the FC to support shadow dom again. As said, not sure about that yet.

Answer 5 · 2022-12-22T09:38:46.000Z

Options can now be set before attachment, will modify initial options on client side.
Initial options from server now only init client side initial options, no more caching on server side.
Migrated plain properties to options, as they currently are already options.
Added some pre-alpha prefetch sample.
Auto browser locale option for FC builder.
FC builder now handles initial options a bit differently (hope does not break anything) - additional "with" calls will hard override custom initial options.
Entry limit constructor deprecated.
Removed eager in memory provider, made lazy in memory provider the "normal" one.
Deactivated some tests.
Deprecated from prev version code removed.

Answer 6 · 2022-12-22T16:02:51.000Z

Started prototyping for resource provider / fetch from server

Answer 7 · 2023-02-16T09:08:06.000Z

Removed Todo "Fetch Resources from Server Side". This will be an optional topic for a later version as the effort is too high for the outcoming results (at least I haven't heard any issue regarding full in memory resources). Also changing that part would bring a bunch of breaking changes, therefore it is out of the list for now

Answer 8 · 2023-04-27T21:44:31.000Z

There is a problem with the calendar.changeView() (#166 (comment))

This is working:

public MainView() {
        setSizeFull();

        FullCalendar calendar = FullCalendarBuilder.create().build();

        calendar.setNowIndicatorShown(true);

        calendar.setSizeFull();

        Button btn1 = new Button("View", ev -> calendar.changeView(CalendarViewImpl.TIME_GRID_WEEK));
        add(btn1, calendar);
    }

The view correctly change when the button is pressed.

There is the problem:

    public MainView() {
        setSizeFull();

        FullCalendar calendar = FullCalendarBuilder.create().build();
        calendar.changeView(CalendarViewImpl.TIME_GRID_WEEK);

        calendar.setNowIndicatorShown(true);

        calendar.setSizeFull();

        add(calendar);
    }

When you try to change the view immediatly it doesn't work.

To test this create a new project with Vaadin 24, download it from https://github.com/vaadin/skeleton-starter-flow-spring/archive/v24.zip

Answer 9 · 2023-05-02T15:30:46.000Z

Should now be fixed. I also fixed the addon and addon-scheduler in the v6 branch to be "V24 ready", so it should be possible to use built jars from that branch with an V24 demo.

Answer 10 · 2023-05-02T21:12:34.000Z

Nice, will test other stuff soon!

Answer 11 · 2023-05-03T06:59:20.000Z

I also added the wiki pages as .md files inside the "/docs" folder and added stuff for release-notes, samples and migration. This could need a second pair of eyes :) (but no need for hurry on that case, this can also be done after releasing the v6)

Answer 12 · 2023-05-04T20:05:49.000Z

Seems to not be fully fixed the changeView problem. It correctly work with calendar.changeView(CalendarViewImpl.TIME_GRID_WEEK); and calendar.changeView(SchedulerView.RESOURCE_TIMELINE_YEAR); but not with custom view

MyCustomView customView = new MyCustomView(75);

calendar = new MyFullTimeline(customView.getInitialOptions());

calendar.changeView(customView);

public class MyCustomView implements CalendarView {
	private final int numberOfDays;

    public MyCustomView(int numberOfDays) {
        this.numberOfDays = numberOfDays;
    }

    @Override
    public String getClientSideValue() {
        return "customResourceTimeline";
    }

    public JreJsonObject getInitialOptions() {
        JsonFactory factory = new JreJsonFactory();
        JreJsonObject initialOptions = new JreJsonObject(factory);
        
        JreJsonObject durationHolder = new JreJsonObject(factory);
        durationHolder.set("days", factory.create(numberOfDays));
        
        JreJsonObject customViewHolder = new JreJsonObject(factory);
        customViewHolder.set("type", factory.create("resourceTimeline"));
        customViewHolder.set("duration", durationHolder);
        
        JreJsonObject viewsHolder = new JreJsonObject(factory);
        viewsHolder.set(getName(), customViewHolder);
        
        initialOptions.set("views", viewsHolder);

        return initialOptions;
    }

    @Override
    public String getName() {
        return "customResourceTimeline";
    }
}

branch v6 with vaadin 14.10.0

Answer 13 · 2023-05-05T01:14:13.000Z

Ok, I would take that as a known issue to be fixed soonish.

Answer 14 · 2023-05-05T12:45:18.000Z

6.0.0 released. Praying for not too much upcoming issues 😄

Answer 15 · 2024-02-08T10:33:26.000Z

One big change with FC6 is, that it does not require to import styles anymore. But of course, they do not had have shadow dom in mind (again), which mean, that the fc will now be slotted and thus styles will be applied like in the light dom. I am not yet sure, if I like this change or not. It will make styling easier, but also has the good old bleeding in of other styles. Currently, there is a lumo styling, that auto applies the "disabled text" color to all links (aka all normal text and numbers in the FC). :/

I am currently experiencing this issue. Is there any easy way to fix it?

Answer 16 · 2024-02-08T11:24:39.000Z

What exactly do you mean / is your issue? And it would be good if you could open a new issue for that with some additional details for us to see and maybe reproduce your problem

Answer 17 · 2024-02-08T11:54:00.000Z

What exactly do you mean / is your issue? And it would be good if you could open a new issue for that with some additional details for us to see and maybe reproduce your problem

I created a new Issue for this.
#184