Currently I'm developing a website using the following stack:
vue.js
#vue/server-renderer
vite
tailwind CSS
SSG was chosen as the rendering mode.
Tailwind, as described in the documentation, allows you to specify directories and file extensions (content property) , in which he will try to find the classes, in order to leave only those that are actually used in the project.
As a result, the 'main.css' file is formed, in which only those classes that are used remain.
Next, I just take this file and include it in every page that was rendered during the build phase of the project.
This results in:
index.html - main.css
about.html - main.css
blog.html - main.css
It turns out that main.css file may contain classes that are needed only for one of the pages and are not needed for others.
I would like to implement the following:
Take main.css which turned out
Render a page, for examle about.html
take only those styles that are needed for about.html page from the main.css file
create a new about.css file
link the resulting about.css styles to about.html
I’ve already tried to implement this using an awesome PurgeCSS tool as following:
render page content usind #vue/server-renderer's renderToString() method;
Pass an resulting css and html sources to PurgeCSS
here is an example
But there are too many corner cases around this solution, such as:
Dynamic classes which can be added to the html on the client side
Some components may be missing in rendered html and their content will be added later (for example, v-if directive was used on the component)
A few takeaways:
PurgeCSS is not needed anymore since Tailwind v2 (the latest being v3.x)
as far as I know, you cannot have code-splitting with Tailwind, not that it matters anyway since it will still perform okay with further optmizations
the classes that will be generated, will be only once for the whole app (hence no need to have a bg-red-500 for index or about page, both are referencing the same unique declaration)
if you want to have SSR/SSG, I recommend the usage of Nuxt (in it's v3 if you're using Vue3 or plan to have anything long-term)
dynamic classes are not possible with Tailwind, you can create things like bg-[#ccc] but it goes on the opposite side of what Tailwind is achieving and should be used exceptionally
for Tailwind's content, still the defaults on this page, section Configure your template paths, no need to do anything crazy or complicated
if you want to have some scoped/local style, style to using style scoped, you can still use Tailwind inside of those tags tho
if you want to write vanilla CSS into dedicated CSS files like index, about, blog etc, then Tailwind is probably not the best approach because this is not how it is supposed to work
stay simple, the performance will still be amazing. Only focus on not having too many screens, colors etc that you're not using
you could run some bundle size tests to see if the CSS is taking a huge chunk in terms of size. Will probably not, but if it still is: you can then start making complex configurations
JS will be far harder to reduce and be more impactful regarding the performance (because of how a browser works with it: parsing, executing is indeed blocking the main thread)
We have an existing website. We'd like to add Vue to areas of the site. Some areas we'd only need a single Vue app to run like a shopping cart. Other areas we'd have multiple of the same component on the page broken up by non Vue items. We'd also like to use single .vue files for our building. I can't for the life of me figure out the best way to do this.
If we use the CLI to build individual apps, we can of course bring those apps in on the pages and where needed. However on the pages where we have the same component separated by non Vue items, it seems we'd need the exact same app multiple times and compiled this doesn't seem to work.
Whats the best route to do this. I'd like to just add a global wrapper to my site, compile a single APP and then house all logic inside components. This breaks down as it replaces my existing content with the app's content when it's a compiled app. I can on the core layout page just instantiate an app and that works, but then I can't use single file components.
Am I missing something. I'd like to use single file components, have a global wrapper on my site with existing content used and components only where needed, AND not have to import each component file one by one.
We cannot use WC builds either as we can't drop IE 11.
I have a header on every page thats generally static — besides the button that needs to update based on the page. Ideally I would like to have a variable called link in static/content/xxx
and then to call it from layouts/default. However it does not seem that I have access to any of the variables in my static content. Being new to vue and nuxt I was hoping for some guidance. I tried using asyncData however, it doesn't seem to get called at all in my layout.
a layout is a static wrapper that will wrap your main content. the main idea behind using layout is to not write the same content again and again. If you work with Vue only project than this type of functionality can be accessed by the using the child routes.
just add the common layout as the parent Component and the changed or different content as the child components.
back to the point, if you have different button content depending upon the pages than don't place it in the layout instead pass through the components individually.
whereas the static folder in the nuxt application holds the data that should not be changed such as the css files or external script files just take and example of bootstrap and jquery these are the libraries that are embeded in the application, instead of changing their internals we just use them. this type of content is placed in static directory (folder)
I hope it helps
I have a very, very simple set of Vue components that all work. These are a simple addition on top of an existing C# app.
At the moment, these are .html files (brought into the app inside <script> tags) and .js files loaded by reference.
These all work, are very light weight, and I love it.
Now I want to compile the HTML for each component into a Vue render function, and the .js into one minified .js file.
The .js to .min.js is pretty standard, but I cannot figure out how to get the HTML to compile into the Vue render function. Everything I've found involves a LOT of overhead and running a web server which seems a massive overkill for an html->script transform, and I don't need a full web application spun up. I only need my existing, simple templates transformed to something more friendly for production than my long-form html templates getting dumped to the page.
I'm not entirely opposed to turning the .html+.js into .vue files, but just doing that doesn't seem to overcome my issue.
I cannot figure out how to get the HTML to compile into the Vue render function
To generate a render function from a Vue template string (e.g., read from an HTML file), you could use vue-template-compiler like this:
const compiler = require('vue-template-compiler')
const output = compiler.compile('<div>{{msg}}</div>')
console.log(output) // => { render: "with(this){return _c('div',[_v(_s(msg))])}" }
Everything I've found involves a LOT of overhead and running a web server which seems a massive overkill for an html->script transform
The "web server" you mention is provided by Webpack CLI, and is intended to faciliate development. You don't need to use the dev server. The article indeed describes several steps in manually setting up a project to build Vue single-file-components, but a simpler method is to use Vue CLI to automatically scaffold such a project.
I just used the command line (CLI) to initialize a Vue.js project. The CLI created a src/components and src/views folder.
It has been a few months since I have worked with a Vue project and the folder structure seems new to me.
What is the difference between the views and components folders in a Vue project generated with vue-cli?
First of all, both folders, src/components and src/views, contain Vue components.
The key difference is that some Vue components act as Views for routing.
When dealing with routing in Vue, usually with Vue Router, routes are defined in order to switch the current view used in the <router-view> component. These routes are typically located at src/router/routes.js, where we can see something like this:
import Home from '#/views/Home.vue'
import About from '#/views/About.vue'
export default [
{
path: '/',
name: 'home',
component: Home,
},
{
path: '/about',
name: 'about',
component: About,
},
]
The components located under src/components are less likely to be used in a route whereas components located under src/views will be used by at least one route.
Vue CLI aims to be the standard tooling baseline for the Vue
ecosystem. It ensures the various build tools work smoothly together
with sensible defaults so you can focus on writing your app instead of
spending days wrangling with configurations. At the same time, it
still offers the flexibility to tweak the config of each tool without
the need for ejecting.
Vue CLI aims for rapid Vue.js development, it keeps things simple and offers flexibility. Its goal is to enable teams of varying skill levels to set up a new project and get started.
At the end of the day, it is a matter of convenience and application structure.
Some people like to have their Views folder under src/router like
this enterprise boilerplate.
Some people call it Pages instead of Views.
Some people have all their components under the same folder.
Choose the application structure that best suits the project you are working on.
I think its more of a convention. Something that is reusable can be kept in src/components folder something that is tied to router can be kept in src/views
Generally re-usable views are suggested to be placed in src/components directory. Examples like Header, Footer, Ads, Grids or any custom controls likes styled text boxes or buttons. One or more components can be accessed inside a view.
A View can have component(s) and a view is actually intended to be accessed by navigation url. They are generally placed in src/views.
Remember that you are not constrained to access the Components via url. You are free to add any component to the router.js and access it too. But if you are intended to do it so, you can move it to a src/views rather than placing it in src/components.
Components are user-controls in analogy to asp.net web forms.
Its just about structuring your code for better maintenance and readability.
Both folders are basically the same since they both hold components, but the aesthetic of Vue is that components that will function as pages (routed to like page for navigation) are kept in the /views folder, while reusable components like form fields are kept in the /components folder.
src/views is typically used for your main pages in the application that you navigate via router.
src/components is used for the reusable components that you use inside your main pages (multiple times inside the same page or across different pages)
Simple, Views are for routes while Components are components of the route.
You can consider Views like page and components are reusable block of code that you can use in any page or components (both are Vue files these terms are just for demonstration)
Less dynamic close to static pages is reffered to views and more reuseable and dynamic content is placed under the components.
It is quite simple, as mentioned by others: you usually use Views for the actual pages you want the user to navigate. Components are the elements inside those pages that you can reuse in any page of your project.
In my view, component folder must contain the components that are going to be used in the views. And in views, there must be those pages that are to be accessed by the router. For example, you have a navbar, header and a footer in your pages to be used and you have a login page, signup page and a main page. Then your src/components must contain header, footer and navbar. And in your src/views there must be files like login, signup and main file.
Both these folders hold Vue components, 'views' folder is supposed to contain root level components where other components would be imported. The so called 'other components' reside inside the 'components' folder. Let's take an example for illustration.
Suppose you have 3 root level pages for a website yourname.com
yourname.com
yourname.com/about
yourname.com/price
Your 'views' folder would have 3 components. 'about.vue', 'index.vue' and 'price.vue'. These files would be imported in your router file or could be directly imported in app.vue file for routing. These views could have multiple components inside them like 'price-card.vue', 'contact-card.vue' and more. These files would typically reside inside a folder named 'components'. You can import these components inside the vue files you have in the 'views' folder and then render them.
Nothing but to arrange the project in logical order. You can still create components in the view folder, but it's a better approach to separate items so that the code is less messy.
The difference is the function they perform. The views are used to represent your pages properly, that you can navigate back and forth, and the components are the parts that compose your page