Unicorn is made up of multiple pieces which are all integrated tightly together. The following is a summary of how some of it all fits together, although it skips over a lot of the complexity and advanced functionality. However, for all of the details the code is available at https://github.com/adamghill/django-unicorn/.
u: and creates a list of attributes that end with
:poll, or other specific
Unicorn functionality. For attributes that are let, the assumption is that they are an event type (e.g.
For all inputs which have a
model attribute, an event listener is attached (either
blur depending on if the
lazy modifier is used). The
defer modifier will store the action to be bundled with an action event that might happen later.
Once a model event is fired it is sent over the wire to the defined AJAX endpoint with a specific JSON structure which tells
Unicorn what the updated data from the input should be. The component class is re-instantiated and the data is updated from the front-end, then re-rendered and the HTML is returned in the response.
Actions follow a similar path as the models above, however there is a different JSON stucture. Also, the method, arguments, and kwargs that are passed from the front-end get parsed with a mix of
ast.literal_eval to convert the strings into the appropriate Python types (i.e. change the string “1” to the integer
1). After the component is re-initialized, the method is called with the passed-in arguments and kwargs. Once all of the actions have been called, the component view is re-rendered and the HTML is returned in the response.
After the AJAX endpoint returns its response, the newly rendered DOM is merged into the old DOM with
morphdom and input values are set again based on the new data in the AJAX response.