Introduction to NikaFramework (NKF). Part 2

    Continuation of the first part .

    4. Project build system
    What I love about build systems for is that I can create many different files and not worry about how to organize this later, so that everything loads quickly on the user side.

    What does the project build system do?
    One simple thing - it takes all the files, packs them in a certain way, and the output we have is one, the only file - index.xhtmlz.
    This allows the developer to create as many files as necessary, for example, divide classes into several subclasses, write styles in several files, and create XHTML presets for any occasion.

    In addition, later we can access the same resources (XHTML, SVG, JSON) using inherited methods without resorting to AJAX, since all these resources are already in index.xhtmlz.

    If the pictures are used in XHTML or in styles (CSS / Sass), then the project build system will convert them to data: URL , when using base64.

    index.xhtmlz (index.xhtml):


    DOM:


    In the future it is planned to introduce support for “annotations”, when using which the resource should not be converted to data: URL, which can be useful for very large files, for example, video.

    The project build system has two modes. development and production. In development (the default), all resources are packed, but JS is not compressed or obfuscated.
    In production mode - there is an additional compression. At the end of the work (in any of the modes) - the
    file is compressed in zip format, which saves on traffic.

    The project build system is written in NodeJS and on average takes 1 second in development mode for an average project (350 files).

    The advantage of using compilation all the time (building the project) is that you always have code that meets the combat conditions, that is, production mode.
    As it often happens, when using a separately connected script / link tag everything works fine, and later when everything is packed into a single file, jambs begin to come out.

    5. Semantics of the generated DOM
    How often did you have to inspect an element (Firebug, Web Developer), and then look for its implementation throughout the code?NKF solves this problem by knowing what type of component each component belongs to, and it generates a DOM that is understandable for quickly finding a component.

    data-nkf-component-type- component type - component
    data-nkf-component-namename





    6. Localization on the fly
    This is an opportunity to change the locale to another without a reboot. This is done using the data- * attribute data-lang- *.

    E.g.


    will end up like this, for English.


    or like that for rus.





    Localization files are created in the / data / lang directory as regular JSON files.

    E.g.

    ru.json:
    {
    	"translate":{
    		"Search": "Поиск",
    		"Products": "Продукция"
    		....
    	}
    }
    


    It is also possible partial localization of the generated part of the DOM and even CSS ( content ).

    In the future, it is planned to make it possible to bind labels to localize large text.

    In the next part I will show how to create applications using this framework.

    PS Constructive criticism and ideas for improvement are welcome.

    Also popular now: