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

[beta.1] how to handle CSS/SCSS with plugin system and ES6/NPM environment? #4490

Open
arshaw opened this Issue Feb 5, 2019 · 5 comments

Comments

Projects
None yet
5 participants
@arshaw
Copy link
Member

arshaw commented Feb 5, 2019

Using a system like NPM with Webpack/Rolllup provides seamless way to bundle all the plugins/dependencies you'll need for your project. For example, if you compile this:

import { Calendar } from '@fullcalendar/core';
import timeGridPlugin from '@fullcalendar/timegrid';

document.addEventListener('DOMContentLoaded', function() {
  var calendarEl = document.getElementById('calendar');

  var calendar = new Calendar(calendarEl, {
    plugins: [ timeGridPlugin ],
    defaultView: 'timeGridWeek'
  });

  calendar.render();
});

...then all the necessary JS will be bundled together: the core js, the timegrid js, the daygrid js (which is depended-upon by timegrid)

However, such a system doesn't exist for the CSS that each plugin depends on. Currently, you'll need to manually include the following CSS files on your page somehow:

node_modules/@fullcalendar/core/main.css
node_modules/@fullcalendar/daygrid/main.css
node_modules/@fullcalendar/timegrid/main.css

(and it's important that they're ordered correctly)

The conventional wisdom for distributing reusable JS plugins that rely on CSS seems to be to leave it up to the developer to decide how they want to deliver the CSS. They can concatenate it together with the rest of the app's CSS, they can @import it from their sass files, or do something else.

But this technique puts a significant burden on the developer when using a system like fullcalendar's which now has a network of plugins that might rely on each other in arbitrary ways. You're forcing the developer to understand the dependency graph.

What should we do about this?

  • keep it as-is. the developer should be responsible for including the CSS files
  • have each of fullcalendar's plugin files that require CSS do a ES6-style import and require the developer to have a CSS loader in their build system. CKEditor does something like this.
  • bundle the CSS within the JS files. have a giant string with CSS that gets attached the document dynamically via the JS. or some other technique of this sort. we'd need to prevent a FUC though.

Thoughts? Please provide pros and cons of each approach.

@arshaw

This comment has been minimized.

Copy link
Member Author

arshaw commented Feb 5, 2019

Follow-up question: should we provide the SCSS files instead of the CSS files for any of the above approaches?

@Twikito

This comment has been minimized.

Copy link

Twikito commented Feb 6, 2019

That's exactly what I was going to ask: could you provide CSS files for those who need them, and SCSS files with config for others?

You know, there are different approaches for styling these days: the three you mentioned, the SCSS method with configurable variables, and the CSS with cutom properties.

I'm currently working on a project with SCSS that set custom properties with configurable variables, in order to be able to theme the UI easily. This way, I can decrease drasticaly the size of the stylesheet, so it would be great if you could provide all these possibilities.

@mariodipatria

This comment has been minimized.

Copy link

mariodipatria commented Feb 11, 2019

Using a system like NPM with Webpack/Rolllup provides seamless way to bundle all the plugins/dependencies you'll need for your project. For example, if you compile this:

import { Calendar } from '@fullcalendar/core';
import timeGridPlugin from '@fullcalendar/timegrid';

document.addEventListener('DOMContentLoaded', function() {
  var calendarEl = document.getElementById('calendar');

  var calendar = new Calendar(calendarEl, {
    plugins: [ timeGridPlugin ],
    defaultView: 'timeGridWeek'
  });

  calendar.render();
});

...then all the necessary JS will be bundled together: the core js, the timegrid js, the daygrid js (which is depended-upon by timegrid)

However, such a system doesn't exist for the CSS that each plugin depends on. Currently, you'll need to manually include the following CSS files on your page somehow:

node_modules/@fullcalendar/core/main.css
node_modules/@fullcalendar/daygrid/main.css
node_modules/@fullcalendar/timegrid/main.css

(and it's important that they're ordered correctly)

The conventional wisdom for distributing reusable JS plugins that rely on CSS seems to be to leave it up to the developer to decide how they want to deliver the CSS. They can concatenate it together with the rest of the app's CSS, they can @import it from their sass files, or do something else.

But this technique puts a significant burden on the developer when using a system like fullcalendar's which now has a network of plugins that might rely on each other in arbitrary ways. You're forcing the developer to understand the dependency graph.

What should we do about this?

  • keep it as-is. the developer should be responsible for including the CSS files
  • have each of fullcalendar's plugin files that require CSS do a ES6-style import and require the developer to have a CSS loader in their build system. CKEditor does something like this.
  • bundle the CSS within the JS files. have a giant string with CSS that gets attached the document dynamically via the JS. or some other technique of this sort. we'd need to prevent a FUC though.

Thoughts? Please provide pros and cons of each approach.

Just what I need to know!!
Perfect!
thanks

@danydhondt

This comment has been minimized.

Copy link

danydhondt commented Feb 12, 2019

One shouldn't reference node_modules directly.
I'm testing with react and this works:
import '@fullcalendar/core/main.css'

@Lamberthassel

This comment has been minimized.

Copy link

Lamberthassel commented Feb 19, 2019

I think it will be better to keep it as-is.
It may look a bit dirty but this approach is the most transparent, a developer could easily understand which styles he/she's importing.
Moreover, some developers may want to write CSS for Fullcalendar from scratch, so it's important to keep the opportunity not to import native styling at all.

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