https://netsuiteprofessionals.com logo
Join Slack
Powered by
Does the `ignoreFieldChange` property on `record.s...
# suitescript
m
Does the 
ignoreFieldChange
property on 
record.setValue()
server a purpose in server-side scripts? Based on the name alone, it seems like it would only impact client-side scripts. In the docs it says 
record.setValue()
is for both client and servers scripts but the property name has me questioning it's value server-side.
a
I think its slightly more nuanced than that, and the documentation does a poor job clarifying. Server-side scripts that load records in dynamic mode, could very much care about the the field change event, serverside in standard mode? i agree with your take, I don't see how that could affect anything.
m
If I have a server-side script with a record in dynamic mode, what's responding to 
fieldChange
events that we might want to ignore?
a
Copy code
Dynamic mode:

When a SuiteScript 2.x script creates, copies, loads, or transforms a record in dynamic mode, the record's body fields and sublist line items are sourced, calculated, and validated in real time. A record in dynamic mode emulates the behavior of a record in the UI.

When you work with a record in dynamic mode, the order in which you set field values matters. For some developers, this aspect might feel constraining. It is likely that scripting in dynamic mode will require you to refer back to the UI often. For example, on an invoice in the UI, you would not set the Terms field before setting the Customer field. The reason is that as soon as you set the Customer field, the value of Terms will be overridden. On an invoice, the value of Terms is sourced from the terms specified on the Customer record. The same behavior happens in dynamic scripting. In your scripts, if you do not set field values in the order that they are sourced in the UI, some of the values you set could be overridden.
so using their example, if you set a customer on your invoice but idk DONT want it to set terms? as it normally would maybe you can ignorefieldchanged, and it won't actually set terms? (overwrite the terms you already set?!) idk I'm not DOING any of this, just trying to answer your question
m
...and I appreciate you trying to help me understand. I get the difference between standard and dynamic and how sourcing works. I don't use 
ignoreFieldChange
much myself except in client scripts, but for some reason other developers where I work specify this property every time they call 
.setValue()
. Since fieldChange is a very specific client script event I was just curious about the impact on server scripts, and there may be none.
a
oh gotcha... in that case it is probably just people that think if a a thing exists you should always explicitly set it? I'm assuming these people are just explicitly setting it to false which is the default value anyway?
do they have a background with a less forgiving language than JS? something more strongly typed?
m
That's an interesting question and might have an impact, but I'm not sure.
a
you have 2 options I guess... ignore it and just bite your tongue.... convince them that explicitly setting values to their default values is weird and it makes you assume they NOT setting default values cos why would you ever do that, so it actually makes their code 1. hard to read/parse/understand 2. more verbose 3. less like the industry standard for SuiteScript
m
I'll likely keep ignoring it even though I don't disagree with your reasoning. I just saw someone else post code that had it and it caused me to question my understanding of that particular property.
a
do they do it consistently? if so I might be uncharacteristically likely to bite my tongue... cos its a good indicator of who wrote what code 😄 unless you have people actually using source control correctly anyway in which case you already have that information
it doesn't HAVE to be conflict, you can just ask humbly instead of attacking them 🙂
they may have other reasons, I'd be kinda curious at this point
m
Don't get me started on source control.... 🙂 Source control and code reviews are new to this team. We're working on it. Per your suggestion, I think I'll ask the next time it comes up in a code review.
a
oh boy, okay yeah, umm take things so slowly and don't rock the boat, if you're starting to get some compliance with source control and code review that's a good thing keep the focus on that... this is pretty superficial by comparison so I wouldn't risk undoing the progress made on other fronts
m
for sure. Thanks for the feedback!
👍 1
67 Views
Open in Slack
PreviousNext
Powered by