IxDF Developer Docs

Appearance

Front-end Architecture ​

Strategy ​

Use the platform. Yes, #useThePlatform. Frontend tooling and libraries are very dynamic and changing at a fast pace for example the never ending new JS frameworks to things like CSS in JS. Our app was created in 2014, imagine how many times we needed to re-write our front end to always be at the bleeding edge. There is only one way be out of hype train and still have modern technologies: use evergreen technologies. In case of web, “evergreen” means native Web API that platform and browsers provide.

We prefer to use polyfills and wrappers on the top of Web API instead of using packages that implement a feature from scratch. This is why we build a team of engineers, not framework or npm users. As IxDF developers, we SHOULD know how things work under the hood.

JavaScript ​

We use ES modules and Webpack module loader for them. We use latest JS syntax and use Babel as a transpiler to make it work on our supported browsers. To read more about assets management please see Assets docs.

Script types ​

There are 3 types of js files existing in our project: modules, components and page scripts.

Modules ​

ES modules. Modules do not do anything with page right after including. Instead, they returns/exports some objects, classes or functions and you should explicitly call them.

Conventions:

  • use camelCase for filenames;
  • provide detailed documentation with examples in order to have perfect documentation generated from JSDocs;

Components ​

Components are mostly used in two capacities, they can either be loaded along with laravel components as their JS counterpart or they can be used to initialize web components. They can be imported either using <script> tag or loaded through import in some parent JS file.

We are transitioning to more and more web components as they provide benefits like easy initialization, shadow dom isolation and component life-cycles.

Conventions:

  • use camelCase for filenames
  • provide detailed documentation with examples

Page scripts ​

Page scripts like controllers in MVC: they can do any logic at the page, load modules and components, make requests using api helpers, etc. Page scripts should always be registered using html <script> tag (do not load them using imports).

Conventions:

  • use camelCase for filenames (some old scripts uses snake_case and kebab-case)
  • provide detailed documentation for every function