I've been using a front-end framework (FEF) to build my app on the platform. I think I'm starting to see the cons of using a FEF with Salesforce, but I'm not sure.

For example, when a user creates a record with a FEF, their data they entered is still on the client. What if there was a trigger that effects some of the values of the fields for the record created? How does a FEF know about the changed field values from the trigger before it display the record on the page?

I use the REST API to do CRUD operations, and there isn't any mention on how it handles CRUD operations when dealing with sOBjects and if their are triggers attached to them.

  • This question seems a bit overly broad. At least the title. – Adrian Larson Mar 15 '17 at 23:34

This is actually something I like to ask potential candidates when interviewing them.

The long and the short of it is that Visualforce is an MVC system. Model-view-controller. If you come from a heavy web development background you're going to be tempted to push as much of the work into the front end as possible as that generally increases the user experience; however, this doesn't quite work with Visualforce for exactly the reasons you mentioned. The data you manipulate on the front end doesn't interact with the data on the back end. This means returning data to the page is not the most straight forward thing to do.

Generally speaking, you "return data to the front end" by updating controller variables and than re-rendering the Visualforce page/components to display the data. This does have the potential for a slightly slower user experience.

You MIGHT be able to help improve the user experience by assuming that your updates to the database are correct. Mimic your back-end behavior on the front-end and process the data all on the front end. Update the database and if it fails, return an error to the user and add a note saying something like "data not saved".

That being said, this could also produce an unfavorable user experience as it may appear that it worked for a moment until they learn it didn't. If they close the page too fast, they may never know that it didn't work.

The short answer is: stop using an FEF. Visualforce doesn't work that way.

Also, look into the apex:status component. You can use this to display a "loading" or "processing" message while the work is committing to the database and the triggers are being fired. Then simply re-render your component.

Lightning Components Everything above applies specifically to Visualforce;Llightning components do not act in the same way. They are designed to perform as much work as possible on the front end to minimize how often you need to reach out to the server. This has many benefits, specifically, reduces resources required on the server and enhances the experience for not just you, but all users on your instance that need those valuable resources. If you are dead set on an FEF solution, use Lightning Components

  • So with Lightning Components, the data you manipulate on the front end does interact with the data on the back end? – Tyler Zika Mar 16 '17 at 15:27
  • Was attending Global Lightning Tour in Chicago just 2 days ago... Yes, Lightning Component (LC) use Callback and other functions to get the status or updated values, and this is similar to what you'll be doing using FEF components. They said "if you developed apps with FEF, keep doing - there is nothing wrong with using them if your developers are familiar with them and delivering what you need." At the same time, LC are always going to be integrated more with SF backend, but also have their limitations.. – o-lexi Mar 16 '17 at 16:05
  • @TylerZika Please don't forget to accept answers to your questions. – gNerb Mar 18 '17 at 17:39

Triggers on the platform never run at client side .They execute at the server always .So using front end framework should not affect anything. Once you do a DML on a record as soon as the sobject records reach SFDC server they will go through the trigger operation before the data is committed to database.

Also triggers do not run on read operation so it does not matter

  • Yes, but what if you want the trigger results to display on the client? You'd have to requery every time you did a CRUD operation, correct? – Tyler Zika Mar 15 '17 at 23:44
  • That's correct .You will need to requery. – Mohith Shrivastava Mar 15 '17 at 23:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.