How to Deploy Angular App to Salesforce: Developer Insights

Hi, I’m Aleksandr Havrylov, a front-end developer at Synebo. I want to share the solution that I came up with during the development of the Angular application for Salesforce, using RemoteActions, StaticResources, and DEV mode, without waiting for the resources to be deployed to Salesforce. This article will show you how to deploy an Angular app to Salesforce without suffering and pain.

Prerequisites / Requirements

You should have basic knowledge and experience in Angular 2+ and Salesforce development. Also, it would be best if you had Salesforce org (version 36.0 and later) for the deployment, evaluation, and validation. The source code is here.

I would recommend using Angular CLI, but this solution will also work for other projects since Gulp works with the project builder. If you do not use the Angular CLI, change the command that builds the project “dev” and “prod” in package.json.

Let’s plunge into this situation. We are in 2018: Elon Musk successfully launched SpaceX; everybody talks about Machine learning, Virtual Reality, Artificial Intelligence. Angular releases the 6th version. Mining and crypto-currencies is common thing. And you would never believe it, but meanwhile, I received a project with the stack of Angular + Salesforce. I’ve found so much stuff on this topic on the Internet. Something from that was good enough and worth of attention, and the rest was a vast mass of rubbish.

My verdict: “Enormous amount of text and a lack of sense is a common denominator.” This was very overwhelming since I thought I could do everything easier. Therefore, I decided to use a minimal set of instruments like Angular and Gulp, which almost every front-end developer is familiar with.

Here is what we get from the Angular+Salesforce stack:   

• Issue connected with joint development
• Only God knows how to work in the development mode
• The build result is not easy to paste in VisualForce page
• How to use RemoteActions?
• How to use StaticResources
• Before deployment on production, we should edit the VisualForce page and so on again and again
• Done with your code=> built it=> made and archive=> deployed=> probably you should be prepared to change your VisualForce page

Enough! For how long can we endure this?!​

Gulp-jsforce-deploy

We first need a Tula to deploy the project to Salesforce, and during the search, I found this post. I decided to stop at gulp-jsforce-deploy, a plugin for deploying prepared packages to Salesforce using JSforce’s Metadata API. This is exactly what we need – easy-to-use and only 3 relations with a simple script for deployment, which is typical for those who have already worked with MavensMate.

The .env configuration file

To not store our sensitive data explicitly in the repository and keep them in one place, we will create a .env file and add it to .gitignore. All configuration settings will be stored because it will not be nice if this file gets into the repository. Dotenv package itself will help us to receive the data.

This is how .env: content looks like. I think this should be clear.

How to use the solution:

1. Copy gulpfile.js from the repository and paste it to your Angular project. Meanwhile, copy the file salesforce.service.ts and paste it to the service folder. Let’s name it src/services.
2. Establish all dependencies with the command​ npm install gulp gulp-zip gulp-jsforce-deploy dotenv gulp-rename gulp-replace gulp-file –save-dev
3. Add commands to package.json “dev”: “ng build && gulp rm && gulp build-dev-package && gulp deploy && ng serve”,  “prod”: “ng build && gulp rm && gulp build-package && gulp deploy”
4. ng build is the command that collects the project. If you do not use the Angular CLI, replace this build command with your project, and if your project does not go to the dist folder, then you need to fix the paths in gulpfile.js.
5. Define the necessary variables in the .env file and run it with the command npm run dev or npm run prod

That’s it! Kindly use it.

Further, I am going to explain how this works:

• Data from the .env file is pulled into the file gulpfile.js
• Index.html from the dist folder is converted into apex: page
• The resource file is created with the name from the .env file based on the build of the project
• *meta.xml files are created for the resources, the page, and the package in general
• We can deploy 2 kinds of packages to our Salesforce Org, entirely ready for production (command: npm run prod) or for development (command: npm run dev) using local resources instead of static resources on our maiden server. For more about this, see below.

You may use StaticResourсes. There is the following script in our gulpfile.js:

This script adds _VfResource to the window object, now this variable is available globally, and that’s how we can use it. In our SalesforceService, there is a getSFResource method that returns the path to the resources.

Here is an example of how you may use it:

some.component.ts

Easy!

Now you may use RemoteActions

There is a method callRemote in our service SalesforceService for this purpose:

The callRemote method in our SalesforceService receives the first parameter with a string containing the Name of the Controller. The name of the Method is the Sampling of the RemoteAction. Additionally, there are parameters (you can edit this as you prefer).

successCallback – processing of a successful response from the server. failedCallback – error handling from the server.

Develop / production mode

As I mentioned before, to deploy prepared to the production project within Salesforce, we have to execute command npm run prod. This will create a package with StaticResources and Visualforce page with connected controllers and resources. If we prefer to work on DEV mode, we have to execute a command npm run dev, which will deploy only the Visualforce page on Salesforce with connected controllers, local resources, and launch Dev Server.

To do so, you should indicate the path to the local resources in the file .env in DEV_RESOURCES_URL variable. For instance, if we use Angular CLI, the path to resources by default will be http://localhost:4200 DEV_RESOURCES_URL=http://localhost:4200

Final Thoughts

I could find only one prominent drawback in my solution. You will have to refresh the page every time you make changes. Unfortunately, Livereload doesn’t work, and have a couple of thoughts regarding this, but let’s leave this for another article.

I hope this solution will be helpful for you and help you be more productive without wasting time on project adaptation and the environment for Salesforce. I will be grateful for your comments and healthy criticism. In case you have additional questions or thought, send emails to contact@synebo.io.