1

I'm working on an application made up of Lightning Components on Community pages. The application has a date field that is allowing various values into it and it's not capturing data correctly on the front end. So, the thought came up of doing some kind of server side validation. Basically, saving the value in the Contact object, then retrieving it and validating it based on that. First, is this even a recommended approach? The process would take 2 Apex calls, one to save and another to retrieve, and to ensure the date gets validated properly the website would have to pause, I'm guessing, to ensure processing before navigating to the next page. The device doesn't appear to matter, but we can replicate the issue in IE11 (which I know isn't technically supported by Lightning, but since the app is public facing we can't keep people from using it, either).

Has anyone performed anything like server side validation on lightning components in communities?

Improve this question
3
  • "The application has a date field that is allowing various values into it and it's not capturing data correctly" - i would try to fix that issue. and if you have code for that godd people of this community might help you to figure that out. – naruto-sfdc Jun 21 '18 at 14:16
  • @naruto-sfdc - thank you, before I post any code (I need some time to collect it together) - is server side validation even a feasible concept in Salesforce given Apex queuing and the possibilities of calls timing out? I can't seem to find much information about this. – ewomack Jun 21 '18 at 16:56
  • did you go through this documentation ?developer.salesforce.com/docs/atlas.en-us.lightning.meta/… it might give you an idea – naruto-sfdc Jun 21 '18 at 17:13
2

There are reasons why you would want to do server side validations on the objects. One of the main reason is if data for the same object is going to come through multiple sources if you put it in UI it will only apply for data entered through that component but if you load data using data loader, through integrations there is a good chance the validations will be by passed if they are not on the object.

Its a design/architecture call that you need to take at the start of your development. for one of our projects we were ok with server calls and bit of performance loss to maintain data integrity.

Whichever ways the data needs to be clean if not then if you have reporting requirements on top of it , you may report on incorrect data.

For the implementation part what you can do is add field level validations and object level validations on salesforce objects.

When you do a DML if there is a validation error the exception can be caught and shown on UI.

Check out this field on how to catch and parse exceptions specifically around getDmlFields

Improve this answer
2
  • this is all great information. Our use case revolves around making sure that validation around various controls on various devices (i.e., mobile, desktop) doesn't let bad data slip in. We need to validate dates (say, something is a particular age) and if the range falls below that range we don't want the record to get past a certain stage in our process. In traditional web applications we would apply a layer of server-side validation above the front-end validation for double insurance of data integrity. – ewomack Jun 21 '18 at 21:30
  • In the scenario you mentioned above, did you have to impose wait times or queue waits for the server-side validation to perform correctly? That's the problem I am experiencing - the page renders and processes prior to the server call completing, so the extra layer of validation gets missed. It's possible that we are just too late to make that architectural change at this point. – ewomack Jun 21 '18 at 21:30
0

I would suggest to do the validation on client side itself. You can do the validation on date field in the Lightning Component JavaScript controller itself before sending the data to Apex for saving.

Another thing is, which aura or lightning component you are using to capture the date field data on UI, is it a Lightning:recordEditform or lightning:input

Improve this answer
4
  • This is interesting - a vendor created the code initially and I see that they changed the control from <lightning:input> to a regular HTML <input> tag. But the tag still has an "aura:id" attribute, so perhaps they meant to keep it as a <lightning:input>? – ewomack Jun 21 '18 at 21:21
  • It doesn't make sense to use html <input> tag, coz If you use <lightning:input type="Date"> it will appears as date picker kind of field on UI. data will always be captures in date format from UI so it System will not led bad data slip in from UI. You can then write additional data validation logic in server side (may be as validation rule or trigger) whatever suits your requirement. – Bhawna Jun 22 '18 at 7:01
  • ok, thanks, I see now why they used <input> rather than <lightning:input>. They didn't want the date picker to render. I'm curious about server side validation using validation rules - have you implemented these yourself? – ewomack Jun 25 '18 at 14:54
  • For the data being entered from a UI, I would not suggest to do server side validations just for verify the data format. You can write a function in your Lightning Component to validate the data before you send it to server. I don't have the exact code with me to validation the Date format in Lightning controller. But I am sure you will find something in google for it. – Bhawna Jun 26 '18 at 6:11

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.