Introduction
AMIS has recently set up a brand new Enterprise Web Application team, of which I am proud to be a member. We will working in front-end development using a variety of Javascript based frameworks. As a first framework, we are currently investigating Oracle JET. After working through the Oracle JET MOOC and a Knockout.js tutorial we have begun to build a meetings organisation app in order to get some more hands-on experience. This app is initially intended to have users and meetings, allowing for the users to create, show, update and delete meetings with their authorization dependent on authentication. This blog post is intended to show you some of the discoveries we made while working on this project.
Getting started
To keep things simple, we started of by setting up a FeathersJS REST API as a back-end with two models, one for meetings and one for users, as well as some seeds to provide initial data for these models. The next step was to make this data available in the JET app, across any of the components which might want to make use of it. This was done through use of the JET model and collection systems. In this system an model is a single data record, while a collection contains multiple records. Since we want the CRUD functionality to be available to different JET components, we placed the code in a separate service as shown below. As you can see, this service defines the model and collection as well as providing an instance of the collection. The parseMeeting and parseSaveMeeting functions and attributes are optional and can be left out if you do not want to change the names of any attributes from back-end to front-end. The comparator attribute of the collection is used to order the different models.
CRUD actions
After setting up the model and collection, we added CRUD functionality. JET models and collections provide functions which take care of the communication with the back-end. For example, when using the create function a plain old javascript object can be passed, as well as success and error handlers. The collection which was instantiated earlier is used to call the create function on, adding the new model to collection for quick availability in the front-end as well as making a call to the back-end to create the object in the database. Specific headers can be used, for example in order to pass an authorization token.
For the fetch and delete methods, we instantiate a new model and set its ID to the ID of the object we want to affect. The relevant function is then called on this object. In the case of the fetch function, the data in the model is mapped to a plain old javascript object, which is returned. In the success handler of the delete function we remove the destroyed meeting from the collection, automatically updating all components in the front-end which rely on its data. The update function accepts both plain javascript objects and JET models.
Calling the service
Setting the service up like this gave us an easy to use way to interact with our back-end, as well as allowing us to clean up the code of our components and remove any duplication. Here is an example of how we call this service from our meetings.js. Other services can be set up in the same way, or multiple services could even inherit from the same base service.
