Open Event Frontend – Settings Service
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 inside its computed method.
Email is received successfully by the recipient:
Finally, the tests pass without errors! Now, we can add some extra convenience functionality: we can also strip the port when it corresponds with the protocol we’re using. For example, if we’re using https protocol, then we need not specify the port if it is 443, as 443 corresponds to that protocol. We can add this functionality by creating a mapping of such correspondence and checking for it before generating the URL. To do this, we now go back to 
You must be logged in to post a comment.