
Derby.js themes for templates
Derby.js offers a mechanism that can significantly increase page loading speed by encapsulating CSS in HTML code given to the client. In production mode, Derby.js minifies HTML, CSS, JS. As indicated in the documentation , Stylus and / or LESS are used.
By default, the file is connected: styles / app / index.styl , where we can take advantage of all the syntactic advantages that Stylus provides.
What if our project provides for the use of several themes (styles) for templates?
UI mechanism - in Derby.js one of the mechanisms that allows you to create custom components. Its feature is that:
So - this is just what we need.
Step by step it will look like this:
In a simplified version, suppose that when you go to the address / page1 , we connect only the styles (or, to put it another way, the theme). In the transition / page2 others, etc.
We will proceed from the position that there are no common styles. Therefore, the
styles / app / index.styl file will only contain:
So, we will execute the following preparatory set of commands:
ui / theme1 / index.js
File ui / theme2 / index.js
Please note that scripts do not have any include files. In this particular case, this is not necessary. However, if you need to add functionality and template tags for a particular component, then you can add the necessary logic at any time.
styles / theme1 / index.styl
styles / theme2 / index.styl
First line
Open the file: lib / app / index.js and fill it with the following contents:
According to our initial idea, we “connect” the theme for specific routers.
If you have a need for introducing themes for a group of routers, then you can put them in a separate file and use the following construction when initializing:
For me personally, the MVC concept is closer, respectively, the breakdown of routers by controllers, which will be more consistent with the action-controller logic. The separation of View and Model is specific, so there is no need to talk about a full-fledged MVC pattern. However, this is a separate topic for discussion.
In the browser, go to:
We examined one of the mechanisms for using multiple styles / themes for templates in Derby.js. The
advantages of this method are that we are relieved from introducing styles that are not used; we significantly expand the set of tools that we can use in for each specific theme by creating Derby. js UI plugin .
The drawback , I see, is that for a fairly simple operation I have to carry out quite a lot of actions, which, it seems to me, could be avoided by more flexibility in structuring the framework logic. However, the latter is very subjective.
Official site Derby.js
derbyjs.com/#stylesheets
learnboost.github.io/stylus
lesscss.org
github.com/codeparty/derby-ui-boot
Materials Derby.js
By default, the file is connected: styles / app / index.styl , where we can take advantage of all the syntactic advantages that Stylus provides.
What if our project provides for the use of several themes (styles) for templates?
UI is our solution
UI mechanism - in Derby.js one of the mechanisms that allows you to create custom components. Its feature is that:
- it can be connected "on demand"
- he can use his styles
- you can implement your own logic of component behavior
So - this is just what we need.
Step by step it will look like this:
$ npm install derby
$ derby new app
$ cd app
In a simplified version, suppose that when you go to the address / page1 , we connect only the styles (or, to put it another way, the theme). In the transition / page2 others, etc.
We will proceed from the position that there are no common styles. Therefore, the
styles / app / index.styl file will only contain:
@import 'nib/vendor'
So, we will execute the following preparatory set of commands:
$ mkdir ui/theme1
$ touch ui/theme1/index.js
$ mkdir ui/theme2
$ touch ui/theme2/index.js
$ mkdir styles/theme1
$ touch styles/theme1/index.styl
$ mkdir styles/theme2
$ touch styles/theme2/index.styl
File contents
ui / theme1 / index.js
var config = {
filename: __filename
, styles: '../../styles/theme1'
, scripts: {
}
};
module.exports = function(app, options) {
app.createLibrary(config, options);
};
File ui / theme2 / index.js
var config = {
filename: __filename
, styles: '../../styles/theme2'
, scripts: {
}
};
module.exports = function(app, options) {
app.createLibrary(config, options);
};
Please note that scripts do not have any include files. In this particular case, this is not necessary. However, if you need to add functionality and template tags for a particular component, then you can add the necessary logic at any time.
STYL File Contents
styles / theme1 / index.styl
styles / theme2 / index.styl
First line
@import 'nib/vendor'
// Дальше вы можете разместить все необходимые стили
We change routers
Open the file: lib / app / index.js and fill it with the following contents:
var app = require('derby').createApp(module)
.use(require('derby-ui-boot'));
app.get('/page1', function(page, model, params, next) {
app.use(require('../../ui/theme1'));
page.render();
});
app.get('/page2', function(page, model, params, next) {
app.use(require('../../ui/theme2'));
page.render();
});
According to our initial idea, we “connect” the theme for specific routers.
If you have a need for introducing themes for a group of routers, then you can put them in a separate file and use the following construction when initializing:
var app = require('derby').createApp(module)
.use(require('derby-ui-boot'))
.use(require('../../ui/theme2'));
For me personally, the MVC concept is closer, respectively, the breakdown of routers by controllers, which will be more consistent with the action-controller logic. The separation of View and Model is specific, so there is no need to talk about a full-fledged MVC pattern. However, this is a separate topic for discussion.
Check
$ npm start
In the browser, go to:
http://localhost:3000/page1
http://localhost:3000/page2
Conclusion
We examined one of the mechanisms for using multiple styles / themes for templates in Derby.js. The
advantages of this method are that we are relieved from introducing styles that are not used; we significantly expand the set of tools that we can use in for each specific theme by creating Derby. js UI plugin .
The drawback , I see, is that for a fairly simple operation I have to carry out quite a lot of actions, which, it seems to me, could be avoided by more flexibility in structuring the framework logic. However, the latter is very subjective.
Sources
Official site Derby.js
derbyjs.com/#stylesheets
learnboost.github.io/stylus
lesscss.org
github.com/codeparty/derby-ui-boot
Materials Derby.js