Components by TJHolowaychuk
The report at the ninth conference "Free Software in Higher Education" , January 25-26, 2014. The source code for notes and examples for them is available at https://github.com/mbykov/articles .
Everyone who works with
')
To seriously work with JS in the browser, we need the code to be modular, so that each module is in its own file, and so that each module can be tested separately and independently of the others. Components - these are the modules that the browser uses, like the npm modules used by node.js. The components differ from the modules created by browserify.js in that browserify uses only npm-modules as “source material” in which there can only be JS, and a component can include css, and html, and fonts, and all together. This simultaneously corrects the fact that css do not have their modular system. And, for example, the removal of any part of the application turns into a problem. If you are using components, removing components along with html, css. etc - almost trivial action.
A component of an application may be, for example, in a network store - a shopping cart. Or any navigation bar, complex menus, etc. It is important that each component is designed and tested separately. On testing components, I will focus more on this later. But the component does not need to have a visible representation on the page. Converting a date or Roman numerals to any local format are typical examples.
Of the two main formats of modules in javascript - CommonJS and AMD - the first component is selected in the components. Components are convenient because creating and adding dependencies, and publishing, and to a large extent even testing takes place in a familiar command line. Working with components is very similar to working with node.js. (Yes, even with Ruby or Python). If you have an idea about node.js, you can work with components. This is beneficial - not only one language - javascript and on the server and in the browser, but also the usual workflow, all the same skills are used. And in many respects the same code. This is an advantageous difference from AMD systems.
For the initial acquaintance, it is best to browse the wiki , especially the FAQ .
The main difference Component from many similar projects - for example, jQuery plug-ins, components are just components. The jQuery plugin can only be used with jQuery. Dojo, Backbone, or MooTools modules - also only in the corresponding infrastructure. Components are just components. They do not require anything to work, and they can be used everywhere, with any system and with any framework. Each component can be generated as a standalone script, and it can be used in the browser outside of any system.
Unlike
The second noticeable difference is the common repository and the component namespace. In the node, your repository, npmjs.org, in the default components is github.com. (You can use your own, of course). Accordingly, the name of the component is username / project. It is very convenient. The name of the author quickly becomes recognizable, and from several similar titles, you can immediately choose on this "sign of quality."
The discussion of these differences with the benevolent dictator of node.js can be found in his blog and in the component-FAQ . Detailed table of differences component vs. browserify prepared G.Stagas .
Yes, to bind all the components of the application into a single
With components, you can usually not use
Angular.js - 709Kb, component / reactive - 47Kb. Reactive is not a complete analogue of Angular, but only its core functionality. But you usually need it, and not all this behemoth.
Aloha.js ~ 1Mb, yields / editable - 4.6 Kb, is also not a complete analogue of Aloha, but only the essence of the matter, which is needed.
There is no typo, 1Mb / 4.6Kb. It is such a monstrous proportion.
In addition, remove the option --dev when
Each component is small, and performs only one task. (Familiar phrase). Because of this, even an average project may require up to hundreds of components. But it only scares at first glance. As a result, even for a large project in a bundled form, non-minified build.js can weigh no more, or about 100 Kb. Components are not just another framework, components are unix-way in the browser.
The most important thing for me personally is that, following this pattern, I can see how literate people perform this particular task. Finding the right place in hippos like Rails, Angular, Django and understanding how this works is not always possible. It can only be strong people, or who has nothing to do. And not often falls opportunity to understand. It works, and okay, he did a deal, and it seems there is nothing to be understood further. And in the components, each of them is quite a visible, simple product that is easy to learn.
Well, what has already been said - a single workflow on the server, in the browser, and, for example, in CouchDB - everywhere work is based on the CommonJS standard.
to be continued
PS What is the correct component or component? let's see what will take root. On the literacy rue it is said that “in all non-terminological contexts one should use the word component”. And here is the terminological context. That is the component, she is. The difference is especially noticeable in a lot. among them, many components or components. Since I choose component-y, in the plural we choose the first option - many components.
- first acquaintance with component - unix way in web programming
- component creation example
- unit testing - console
- unit testing - express
- unit testing - browser
- make vs. gulp vs. grunt & watch
- Z's dead baby
- components and couchapps
Everyone who works with
node.js knows TJ Golovaychuk, the author of the express web server, the mocha testing library, and so on and so forth. But, probably, his most brilliant project for today is the Component - http://github.com/component . In Russian there is still a little literature on components, I will try to fill this gap. TJ posted the first Components report on his blog on December 19, 2012. Now, after explosive growth, the number of components is already over a thousand , and it is growing every day.')
To seriously work with JS in the browser, we need the code to be modular, so that each module is in its own file, and so that each module can be tested separately and independently of the others. Components - these are the modules that the browser uses, like the npm modules used by node.js. The components differ from the modules created by browserify.js in that browserify uses only npm-modules as “source material” in which there can only be JS, and a component can include css, and html, and fonts, and all together. This simultaneously corrects the fact that css do not have their modular system. And, for example, the removal of any part of the application turns into a problem. If you are using components, removing components along with html, css. etc - almost trivial action.
A component of an application may be, for example, in a network store - a shopping cart. Or any navigation bar, complex menus, etc. It is important that each component is designed and tested separately. On testing components, I will focus more on this later. But the component does not need to have a visible representation on the page. Converting a date or Roman numerals to any local format are typical examples.
Of the two main formats of modules in javascript - CommonJS and AMD - the first component is selected in the components. Components are convenient because creating and adding dependencies, and publishing, and to a large extent even testing takes place in a familiar command line. Working with components is very similar to working with node.js. (Yes, even with Ruby or Python). If you have an idea about node.js, you can work with components. This is beneficial - not only one language - javascript and on the server and in the browser, but also the usual workflow, all the same skills are used. And in many respects the same code. This is an advantageous difference from AMD systems.
For the initial acquaintance, it is best to browse the wiki , especially the FAQ .
versatility
The main difference Component from many similar projects - for example, jQuery plug-ins, components are just components. The jQuery plugin can only be used with jQuery. Dojo, Backbone, or MooTools modules - also only in the corresponding infrastructure. Components are just components. They do not require anything to work, and they can be used everywhere, with any system and with any framework. Each component can be generated as a standalone script, and it can be used in the browser outside of any system.
component.json
Unlike
node.js (and, respectively, browserify.js ), each component requires a component.json file, similar to package.js . For those modules that are planned to be used in both environments, and on the server, in node.js, and in the browser, this feels like brute force. Win - simple, clean and clear code, and in both files, and in the component itself. Specification component.json .namespace: github / author / project
The second noticeable difference is the common repository and the component namespace. In the node, your repository, npmjs.org, in the default components is github.com. (You can use your own, of course). Accordingly, the name of the component is username / project. It is very convenient. The name of the author quickly becomes recognizable, and from several similar titles, you can immediately choose on this "sign of quality."
The discussion of these differences with the benevolent dictator of node.js can be found in his blog and in the component-FAQ . Detailed table of differences component vs. browserify prepared G.Stagas .
extra stage?
Yes, to bind all the components of the application into a single
build.js , you have to enter an additional step - make build . But all the same, when working with javascript, we inevitably perform preliminary steps - we need to transform a coffer script, transform sass, chase jshint, package, etc, etc., etc. So another component of this process is not at all noticeable in the work. All together, it is always executed with just one make or grunt , gulp , so this, by and large, is not a disadvantage at all.size matters
With components, you can usually not use
jquery , underscore , etc, etc, etc. For example, if you need to use each or map - do not put jquery for this, or underscore , but require(component/each) - a few lines and you have cross-browser code. And so on every method. As a result:Angular.js - 709Kb, component / reactive - 47Kb. Reactive is not a complete analogue of Angular, but only its core functionality. But you usually need it, and not all this behemoth.
Aloha.js ~ 1Mb, yields / editable - 4.6 Kb, is also not a complete analogue of Aloha, but only the essence of the matter, which is needed.
There is no typo, 1Mb / 4.6Kb. It is such a monstrous proportion.
In addition, remove the option --dev when
make build . In addition, Charlotte Gore 's Flatinator will look, it reduces the code by removing unused aliases. In addition, even more compactness is promised in v1. This is all up to minification and compression.unix-way
Each component is small, and performs only one task. (Familiar phrase). Because of this, even an average project may require up to hundreds of components. But it only scares at first glance. As a result, even for a large project in a bundled form, non-minified build.js can weigh no more, or about 100 Kb. Components are not just another framework, components are unix-way in the browser.
the most important thing for me
The most important thing for me personally is that, following this pattern, I can see how literate people perform this particular task. Finding the right place in hippos like Rails, Angular, Django and understanding how this works is not always possible. It can only be strong people, or who has nothing to do. And not often falls opportunity to understand. It works, and okay, he did a deal, and it seems there is nothing to be understood further. And in the components, each of them is quite a visible, simple product that is easy to learn.
Well, what has already been said - a single workflow on the server, in the browser, and, for example, in CouchDB - everywhere work is based on the CommonJS standard.
Installation:
<pre> $ sudo npm install -g component $ component --help . . . </pre> to be continued
PS What is the correct component or component? let's see what will take root. On the literacy rue it is said that “in all non-terminological contexts one should use the word component”. And here is the terminological context. That is the component, she is. The difference is especially noticeable in a lot. among them, many components or components. Since I choose component-y, in the plural we choose the first option - many components.
Source: https://habr.com/ru/post/209350/
All Articles