The Challenge
Creating a service that will be fast and easy to use while displaying information and flows from various sources and with different data structures.
Concept
We wanted to create the best looking, most intuitive and easy to use interface. Hence we’ve planned and designed a web interface based on Google’s Material Design principals and guidelines. The main entity in the system is – ‘Conversation.' The system was built around it with all the necessary functionality needed for managing it. The conversation page is assembled from various time-saving and information-displaying components which are dynamically updated for an optimal flow of work.
5 Facts about Project
Fact 1
When we started working with eBay’s, we found that there are various of message-selecting methods within eBay’s API documentation, but not one of then enabled selecting messages by a chain order. To solve this issue, we’ve created a special algorithm which analyzes each message and identifies his place in the chain of messages between eBay users.
Fact 2
The application uses localStorage to save data between sessions. When the user connects an eBay or a Gmail account, a pop-up window opens where he logs in to his account and gives us access. After that, we need to send the account information to the API and close the window. The problem is that after this, you need to update the parent window dynamically. Since all data updates occur through redux-actions, a mechanism for saving the last action in localStorage was written. So, if you successfully log in to your account, a callback action takes place, which sends data to the API, the action is written to localStorage, and the window is closed. In the parent window, changes are heard to localStorage, and if the last action in the memory and action does not match in localStorage, this action is called in the parent window without unnecessary sending of data to the API. As a result, the parent window is synchronized with the child window.
Fact 3
All the application data is stored in the redux repository, In the reactive components it’s transmitted through a special function - connect. But, with the complication of the data structure, there are duplications in the data. For example, if the necessary data in the store were on the path store.orders.item – this path should be necessarily registered in the properties (props) of components which use this data. Hence the obvious problem: when you change the location of data in the redux store, you have to update the properties in all the components that are connected to this data. To separate react and redux logic, selectors have been added. For each required data portion, a function is written that takes the state of the storage in the arguments and knows how to find the required portion. In reactive components, the required selector is called instead of duplicating the storage to obtain the required data. As a result, if something changes in the redux repository, only the selector will need to be updated, without affecting the reactive components.
Fact 4
In the process of developing the first version of Subivi, we’ve found that the PHP SKD for working with Gmail API is in Beta, therefore with many bugs, flaws, and missing functionalities. To overcome this problem, we’ve written modules for exponential backoff, special error handler and much more.
Fact 5
Since the source code of the system is modular, instead of assembling one large js file that contains all the components, a modular assembly was implemented. The largest modules that represent the pages of the system are assembled into separate js files and are only connected as needed. This method reduces the time of the first boot of the system, which will grow with the development of the system.
TECHNOLOGIES
