Skip to content

Home

Jump to bottom
Tyll Weiß edited this page Mar 9, 2016 · 25 revisions

Welcome to the PackageFactory.Guevara wiki! This page hosts developer documentation and conventions.

Getting Started

Please follow the instructions in the README for getting started! This documentation is mainly for developers of this package.

Overall folder structure

The JS frontend of this code resides in Resources/Private/JavaScript.

As this package uses a Guest iFrame for rendering the actual website, we have two JS contexts which communicate with each other. The "outer frame" which contains the Neos UI is called host, while the iFrame containing the website is called the guest.

This structure is reflected in the sub-folder/package structure:

  • Host: the main application of Neos.
    • This is the React.JS/Redux application.
  • Guest: the connector running inside the guest frame.
  • API: the draft for the soon to be separated Neos JS API which handles the communication with the server instance.
    • The API is bootstrapped in the root of the Host application, since it relies on the csrfToken of the logged in user.
  • Login: The login screen. Currently not used.
  • Shared: helper functions which are necessary both inside the guest and the host.
    • Should not contain state!
    • We try to get rid of these functions!

TODO: explain how the guest and the host frame communicate.

Our Style of Writing React.js components

We embrace the usage of stateless components as much as possible with the relatively new functional stateless components from React which where introduced in v0.14. In our containers we use the ES2015 class syntax, combined with the react-redux @connect decorator. The combination of both increases the separation of rendering and glue-code for the state.

State and redux

We use redux to manage our state, and as described before we ban state from our react components. We also incorporate a bunch of packages like redux-actions for reducing the code you need to write for creating actions, redux-saga for managing complex and asynchronous actions and action collections, so called sagas.

Sagas are our main pillar of complex, asynchronous, conditional action sequences. For example, in case of the page tree we need to cover sequences like the following example:

  1. UI toggle page tree item
  2. Check if the children are already loaded
  3. In case the items are already present in the state, just toggle the sub tree.
  4. If not, load them
  5. Display the loading icon in the UI
  6. As soon as the data got successfully loaded, append them to the store
  7. If added to the store, hide the loading icon
  8. In case the loading of the data failed, display the error icon
  9. Finish it all by toggling the sub tree.

You see, this is a lot of conditional logic, which is also asynchronous since we need to fetch data from the server. For this purpose we use Sagas, which rely on generators and include all of the above statements.

In our reducers we use plow.js which enforces immutable data and includes a bunch of helper functions for working with nested object structures. This library can optionally return, and we use it pretty much everywhere, curried functions.

If you don't know what a curry function is, you should read this nice interactive tutorial on functional programming. In the longer run we will also re-add immutable.js again.

Testing

We strive to a full coverage of the code base, not only by using unit, but also end to end tests before each release. Unit tests are executed by karma, results are asserted by chai and you can mock / spy using sinon.

Adding unit tests is fairly simple, just create a file ending with .spec.js on the same folder level of your module you want to test, and it will automatically be executed by karma on the next run. Executing just one certain test is possible, just append an .only at the beginning of your itor describe block. F.e. instead of describe('my component', ...) you need to write describe.only('my component', ...) and chai will only assert this block and all of it's children.

We also have a convention regarding naming the most outer describe block. To make debugging easier in case of a failed test, we add the location of the test to the name of the outer describe block. For example if your test is located in Host/Redux/UI/myModule/ you should begin the test with a wrapping describe block

import myModule from './index.js';

describe('"host.redux.ui.myModule" ', () => {
    // Either your "it()" or nested "describe()" blocks.
});

What makes a unit test good? It should the main specification, and thus be easy to understand. Your code and unit tests should also cover cases of misuse, f.e. if you expose a method addTodo and the method requires the first argument to be an object, and a developer or maybe even the API passes an array by accident instead, you should add a type check against the argument and throw an error in case of a miss use.

Redux State Structure

TODO

Functional Programming Basics

TODO

Glossary

  • Node
  • StoredNode
  • StoredNodeType / NodeType
Clone this wiki locally