Remove Unused Class/ID Styles

Feature Request
#1

Now that the incredible new design panel is live in v1.9.2 - I am ecstatic. thank you.

would like to request an improvement further to this:
ability to remove unused Class/ID styles. by unused i mean the class or ID is not applied to any element on a given page or through the project.

having this as a central option for the whole project would make more sense.

a separate ‘remove unused styles’ screen can have list of classes and ID names which are nowhere used in the entire project.

this will allow flexibility to do a lot of experimentation without worrying about unnecessary bloat code aggregating into the project.

what say?

Safe No Code Change Mode on Save
My Beef with Bootstrap
#2

@nshkrsh I like that idea.

1 Like
#3

so it’ll be great if you can please vote for it.
image

Support for other frameworks other than Bootstrap?
#4

I think this is a good idea and would be a great feature, but perhaps difficult to implement.

Do you mean removed unused classes/IDs from custom styles or all styles, including the styles in Bootstrap and/or the styles which are part of the Wappler extensions? If you excluded Bootstrap, it would probably make it much easier - but from the point of view if optimisation, Bootstrap is probably the main issue.

One of the difficulties of removing styles is that some may be used dynamically - ie not appearing on a page, but applied at runtime via Javascript for example. Simply stripping out all classes not referenced on any page could have unfortunate results. However given that Wappler ‘knows’ what classes might be used in this way - as long as only Wappler components are used - I would have thought it should be possible to remove unused CSS reliably, though dealing with such classes that might be used by Bootstrap might be a problem.

This cropped up in a thread some time ago. I suggested it might be possible to integrate Gulp for example with one of the modules available for this purposes. In fact you could do this now from within Wappler, using the terminal with modules such as those mentioned here. You would need a list of classes to be excluded to avoid the problems I mentioned. However it would certainly be nice to have a feature built in.

1 Like
#5

Hello guys,
We’ve already discussed this with the team, during the process of developing the Design Panel.

Such a feature is planned and it will be integrated in the future.

5 Likes
#6

Great. Do you know yet if this would remove all unused CSS or just CSS added via the Design Panel?

#7

We are planning this to be part of much larger project wide refactoring possibilities in Wappler.

So we will be building a whole cache database within Wappler containing all the project meta info. Like all the links between files, used assets, used css names, used Server actions and in which files exactly.

Having that meta info will allow us to do a lot of project wide actions like links updates, assets updates and indeed css clean up.

The minor down side is that the project and all its files have to be indexed first, but that is a one time action. After that it will be all kept up to date.

Having all this indexed will give us a lot of power for smart project wide actions.

This is a big undertaking however so it will take a bit to get it done :slight_smile:

10 Likes
#8

This sounds really exciting. It could increase the ease and possibility of developing large applications with Wappler.

1 Like
#9

That will be amazing @George

1 Like
#10

So changing the name of the page will change all the links to that page like I asked before?

1 Like
#11

that is also part of the big plan yes :slight_smile:

1 Like
#12

bootstrap will be coming from CDN mostly, so that can be excluded IMO.

sounds awesome.

#13

That’s a fair point. However, if there were an option to remove unwanted CSS from Bootstrap, it might be worth considering using a local version. I imagine a small percentage of the Bootstrap classes are actually used in a typical project. Also, if you are using a custom version, or one of the Bootswatch versions, then it will probably be local.

#14

this looks like something which might come in handy for a project with heavy bootstrap customisations.

#15

does this plan also include ability to rename classes as well?

#16

yes but currently we can not rename it on all pages that use the css class.
So if we implement it now - it will just rename class rename on the current page.

Later when we have the project assets and usage index - we can do global renames and refactoring like this.

2 Likes
#17

I’ve never done any heavy Bootstrap customisation, but of course once you do any customisation you would normally have to host the file locally.

Having said that, if you simply create a custom.scss file with 10 or so lines, and recompile bootstrap.css, many changes - probably 100s - are made in the file, so perhaps this would be considered ‘heavy’ customisation.

In any event, the developments in the pipeline sound extremely useful and interesting.

#18

A good library based solution suggested here: