Event Management

This blog illustrates how the settings of a particular user are obtained in the Open Event Frontend web app. To access the settings of the user a service has been created which fetches the settings from the endpoint provided by Open Event Server. Let's see why a special service was created for this. Problem In the first step of the event creation wizard, the user has the option to link Paypal or Stripe to accept payments. The option to accept payment through Paypal or Stripe was shown to the user without checking if it was enabled by the admin in his settings. To solve this problem, we needed to access the settings of the admin and check for the required conditions. But since queryRecord() returned a promise we had to re-render the page for the effect to show which resulted in this code: canAcceptPayPal: computed('data.event.paymentCurrency', function() {     this.get('store').queryRecord('setting', {}) .then(setting => { this.set('canAcceptPayPal', (setting.paypalSandboxUsername || setting.paypalLiveUsername) && find(paymentCurrencies, ['code', this.get('data.event.paymentCurrency')]).paypal); this.rerender(); }); This code was setting a computed property inside it and then re-rendering which is bad programming and can result in weird bugs. Solution The above problem was solved by creating a service for settings. This made sense as settings would be required at other places as well. The file was called settings.js and was placed in the services folder. Let me walk you through its code. Extend the default Service provided by Ember.js and initialize store, session, authManager and _lastPromise. import Service, { inject as service } from '@ember/service'; import { observer } from '@ember/object'; export default Service.extend({ store       : service(), session     : service(), authManager : service(), _lastPromise: Promise.resolve(), The main method which fetches results from the server is called _loadSettings(). It is an async method. It queries setting from the server and then iterates through every attribute of the setting model and stores the corresponding value from the fetched result. /** * Load the settings from the API and set the attributes as properties on the service * * @return {Promise<void>} * @private */ async _loadSettings() { const settingsModel = await this.get('store').queryRecord('setting', {}); this.get('store').modelFor('setting').eachAttribute(attributeName => {   this.set(attributeName, settingsModel.get(attributeName)); }); }, The initialization of the settings service is handled by initialize(). This method returns a promise. /** * Initialize the settings service * @return {*|Promise<void>} */ initialize() { const promise = this._loadSettings(); this.set('_lastPromise', promise); return promise; } _authenticationObserver observes for changes in authentication changes and reloads the settings as required. /** * Reload settings when the authentication state changes. */ _authenticationObserver: observer('session.isAuthenticated', function() { this.get('_lastPromise')   .then(() => this.set('_lastPromise', this._loadSettings()))   .catch(() => this.set('_lastPromise', this._loadSettings())); }), The service we created can be directly used in the app to fetch the settings for the user. To solve the Paypal and Stripe payment problem described above, we use it as follows: canAcceptPayPal: computed('data.event.paymentCurrency', 'settings.paypalSandboxUsername', 'settings.paypalLiveUsername', function() { return (this.get('settings.paypalSandboxUsername') || this.get('settings.paypalLiveUsername')) && find(paymentCurrencies, ['code', this.get('data.event.paymentCurrency')]).paypal; }), canAcceptStripe: computed('data.event.paymentCurrency', 'settings.stripeClientId', function() { return this.get('settings.stripeClientId') && find(paymentCurrencies, ['code', this.get('data.event.paymentCurrency')]).stripe; }), Thus, there is no need to re-render the page and dangerously set the property…