Discussion - Tailwind plugin and SlotResizeStepDuration prop

[amoscicki]

Hi,
I am experimenting with this great calendar!
I am trying to achieve something that I hope someone could help with.
I know i can change slotDuration but that also affects the calendar display.
Would it be possible to maintain 30 minute grid, while making it possible to alter the behaviour of resizing events so that those can be extended/shortened by 5 minutes while stretching?

Best regards!

[vkurko]

Hi,
Yes, you are right, now the step is set by the slot duration. Do you know of any setting from FullCalendar that would help solve your problem?

[amoscicki]

I never used FullCalendar so unfortunately no. I'm thinking of forking the project to dive a little into this project.
What I so far think might be useful for future consideration apart from slotResizeStep is
integration with tailwind (currently trying to apply any tailwind classes to any parts of calendar it doesn't work, potentially because those are dynamically added to the markup so CSS postprocessor doesn't see them until the runtime)
so that packages such as skeleton.dev can talk with the calendar
For now I simply added zoom control that is bound to the slot size prop. Will do the job until I figure this out.

I will try to see if I can add some static classes to the components later today. Also some styles seem to be applied using style markup which takes precedence over class (I think it may mainly be the object sizing when you stretch them etc. so may not be an issue) .

--edit
On the topic again I worked around that for now by creating a zoom control that adjusts the slot dynamically

[vkurko]

Yes, I wanted to try switching completely to tailwind. But I haven’t gotten around to it yet.

However, the calendar right now supports changing the css classes it uses internally. Look at the theme option.

[amoscicki]

I should be able to pretty easily and quick get your current styles translated into tailwind classes.
One of the main things to address is relativity when applying styles.
The same class has different styles based on the parent child tree structure which doesn't really fit tailwinds principles that well

There is some ways around it I can think of for example using constructions like [&>div]:bg-red on the parent element

[amoscicki]

You can find prototype of the plugin here

I deliberately left current structure as it is to make the transition easier to follow.
I mapped each block with tailwinds equivalent classes for desired outcome.
Some classes are would look questionable and likely benefit from applying some standard classes, but idea was to keep current outcome possibly unchanged (example:
[box-shadow:_'0_1px_3px_0_hsla(var(--ec-hs),_50%,_.15),_0_4px_8px_3px_hsla(var(--ec-hs),_50%,_.15)'])
There would be some key concept decisions to make

[vkurko]

When I was thinking about switching to tailwind, I assumed that I would have to change the set of CSS classes that are used inside the calendar. That is, the structure of the theme option had to change too. It seems to me that we need to move in this direction. Otherwise, linearly replacing one current CSS class with several classes from tailwind without changing the internal code that assigns these classes to elements will lead to a very confusing result.

[amoscicki]

My goal here was to do some baby step preparation for the move.
The whole concept of tailwind is to use reusable atomic classes so you never need to dig into your CSS config. You simply amend the class list members.
It feels messy at first but once you get used to it you start feeling how quick and easy this is to maintain in the long run.

I assumed you want to maintain backwards compatibility as much as possible. Please correct me if that is a wrong assumption.

The way I think this could be approached:

Firstly, mapping tailwind classes onto existing structure, more so as a reference for the next steps.
This will also highlight where base tailwind classes are not providing required utilities and some of the recurring patterns of CSS settings that can be turned into some configurable utility settings where instead of using color variables you can just provide a class name like "ec-ghost-red-600" and that will apply for example the background and default font colour that is contrasting enough (we can apply some colour wheel principles)

Now the next step is to prepare flattened CSS for each view which then can be broken into set off classes for each theme prop.
If I'm not mistaken each view at present uses same set of classes that are just modified by the CSS right?

I wanted then potentially extend the themes interface plugin so that when you keep defaults and add additional classes it will try to work out the correct sum of sets and replacing/removing redundant ones when some collision detection is triggered

That way by changing set of classes for single element you are not affecting anything else and the whole idea and promise behind tailwind is based on that principle.

[vkurko]

I assumed you want to maintain backwards compatibility as much as possible.

For tailwind I would release a new major version.

Probably the theme option should still be similar to what it is now. That is, each object property is a group of CSS classes that are assigned to a specific calendar element.

{
  button: 'border border-solid p-1 text-base rounded',
  day: 'flex-shrink-0 border-t-0',
  ...
}

This way you can customize the appearance of each element individually.

[amoscicki]

yeah this is pretty much my goal, and you technically can avoid having plugin for that all together, this is literally a theme for your existing functionality replacing for instance ec ec-event with tailwind utility classes.

Then as for plugin it would only make sense if you decide to extract common settings into dynamically interpreted ones.

It would for example make sense for anything that is described using variables.

[amoscicki]

@vkurko
I am slowly working through the stylesheet and trying to achieve the same looks while using tailwindcss only as next step.

This proves to be a lot of trial and error. It does look like some of the applied classes not necessarily going through the themes object.

Do you happen to have some documentation that would point me to the files that are applying them and maybe explain on some example the flow of the themes object to make it a little easier for me?

I'm probably going to pick this up again Friday or Saturday but I would like to complete next stage of the transition - complete removal of any existing CSS files while maintaining the current looks.

Steps to follow would be:

• Addressing the tailwind classes that need to be parsed and replacing them with standard ones. That will come at a cost of minimal changes to the layout (i.e. instead of fixing some padding to 5px we will get padding of 4px coming from standard in the library etc.)

• Adding variant classes to control variables

Cleanup and discuss how to embed this into project (I think backwards compatibility should be achievable)

edit

And just to expand on my query a bit,
Not expecting you to have detailed documentation on it or prepare one.
Pointing me towards right files and right ideas on how you have/see applying classes implemented will be good enough.
Since we are using tailwind it may also be worth considering complete removal of any applications of style in favour of classes.

I know it will be tricky as this would mainly have its use in defining width and height and that results having a class for each possible object size so there is a possibility that it has to stay that way for this reason alone.

[vkurko]

Do you happen to have some documentation that would point me to the files that are applying them

Unfortunately no. But you can simply search the source files for the theme variable and that way find all the places where it is used. I think this is almost any .svelte file.

explain on some example the flow of the themes object to make it a little easier for me

If I understand your question correctly, the theme option works like this. It can be specified as an object or a function. Everything should be clear with the object.

If it is passed in the options root, then it is applied to all views:

options = {
  theme: {
    // applies to all views
  }
}

If it is passed inside views, then it is applied only to a specific view:

options = {
  views: {
    timeGridWeek: {
      theme: {
        // applies to timeGridWeek only
      }
    }
  }
}

Things are a little more complicated with the function. The function receives as an input parameter the theme object that was created in the previous step. What the previous step is is best illustrated with an example:

options = {
  theme: function themeRoot(theme) {
    console.log('themeRoot');
    return theme;
  },
  views: {
    timeGridWeek: {
      theme: function themeView(theme) {
        console.log('themeView');
        return theme;
      }
    }
  }
}

If there are several views in the calendar, then for example for dayGridMonth only themeRoot function will be called and its result will be used as a theme for this view. But for timeGridWeek, creating a theme object will take place in two steps: first, themeRoot will be called, and then themeView will be called with the input parameter being the result from themeRoot. Accordingly, the result from the themeView function will finally be used as a theme for timeGridWeek.

It’s also worth saying that the same mechanism is used inside the calendar to override the default values of the theme object for different views. That is, the complete chain of calls will be like this:

1. T0  // default theme object (internal)
2. View(T0) => T1  // each view overrides T0 (internal)
3. UserThemeRoot(T1) => T2  // if user passes a function in the options root, its input parameter is T1
4. UserThemeView(T2) => T3  // if user passes a function inside `views`, then its input parameter is T2

[amoscicki]

Thank you for that. Very helpful.

Just a last question for now, are there any classes applied that are not going through the themes flow and are rather hard coded?

[vkurko]

are there any classes applied that are not going through the themes flow

Such classes should not exist. Let me know if you find them 😄

[salvinoto]

Came across this and was trying to piece together the conversation, but essentially if I use the options, I could style elements with tailwind directly?

[vkurko]

Yes, you can completely replace the classes with others, for example tailwind. The only problem you can face is that now the same class can be used in different places, for example ec-days, etc. Perhaps this fact will prevent an easy transition to another css framework. In general, I had an idea to switch to tailwind in the future. If you succeed, please share the result 😃