# Design Principles ## Events as meaningful Actions Events should be triggered by meaningful data actions rather than simple UI interactions. For example, consider a registration process described below: ``` 1. User fills up form [UI Event] 2. User clicks on Submit button [UI Event] 3. Data is sent to API [Data Action] 4. API returns a success or failure status [Data Action] ``` A successful registration can just be assumed by the stage 4, where the fetching promise is settled with the respective response, therefore is where the event trackig is supposed to be placed. ## Action Objects Describe State Changes to the Store An action object describes changes to the store. Actions are the only source of information for the store. See more: [Redux Documentation](http://redux.js.org/docs/basics/Actions.html). ## Use Flux Standard Action (FSA) For better results on your events semantics, comply with [the Flux Standard Action](https://github.com/acdlite/flux-standard-action) reccommendations. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://isaquediasm.gitbook.io/tracking-middleware/getting-started/design-principles.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.