https://netsuiteprofessionals.com logo
Join Slack
Powered by
there seems to be an issue with Chrome that when y...
# suitescript
m
there seems to be an issue with Chrome that when you try to use an 
alert()
with 
validateField
the blur/focus events fire in a loop.
m
I've had a case open with support about this issue for about two and a half years, and I know it also happens in 2.0 and I'm fairly certain it happens with the N/ui/dialog module as well as the native alert. I'm frankly surprised that this doesn't seem to affect too many people's customization, because it's definitely limited our ability to do a lot of custom field validation. As a 'temporary' workaround (that's looking more and more like it's just how life's going to be in NetSuite), I set the value in the field being validated to blank so that it doesn't trigger the validation in a loop.
If you come up with any other ways to deal with this though, please let me know - I feel like it's pretty bad UX to set a field to blank rather than leave the existing value and have the user attempt to fix it.
m
I agree. And I’m running one more test but I think I might have a better workaround
m
I'd love to hear what you come up with if it ends up working out
m
So this seems to work correctly
Untitled
Untitled
Basically I allow the alert to render. Then I save the function of the current 
onblur
event attached to the validating field. Then I “reset” the 
onblur
event attached to the input to an empty function, then I allow a quick timeout for the browser to attempt its on built in behavior and then I refocus the field leaving the original value and then reattach the original onblur event
m
Interesting. That seems pretty far down the path of unsupported DOM manipulation but that might be a worthwhile trade-off for working around a defect that they seem to be ignoring.
What's 
field
in that code, is that from 
context.currentRecord.getField()
?
m
I agree, but I’m using vanilla javascript to implement the behaavior
Copy code
var field = document.getElementById(id);
m
Ah sure, makes sense
m
the input element on the UI happens to have the same NS ID
m
So as long as they don't obscure those input elements' IDs that should continue to work
👍🏾 1
m
that’s actually how I’m determining if elements are actually visible as well
Copy code
document.getElementById(id).parentNode.style.display.toUpperCase() !== 'NONE'
this is how I determine if the control is even on the page before I bother to attempt validating it
because there isn’t any built in method to do it, and the 
nlobjField
methods seem to only give you the SuiteBuilder state of the fields you attempt to target
m
I'd say I'm surprised that the field object you can get from 
context.currentRecord
doesn't have a 
displayType
property, but nothing really surprises me anymore with NetSuite...
m
it doesn’t actually change the 
hidden
or 
visible
or 
display
properties of the field object when you use something like 
nlobjField.setDisplayType()
the number of undocumented methods is beyond aggravating
I spend most of my day “discovering” how to make NetSuite work with itself. lol
m
Oh wait, maybe there's no 1.0 equivalent, but the 2.0 does (supposedly) have a 
isVisible
property that's just a boolean
m
yes. 2.0 does
m
It sounds like you're stuck in 1.0 for this project?
m
unfortunately I haven’t even had the time to dive into 2.0 syntax
m
Yeah, I'm glad I've started using it more recently but depending on how big your project is it can definitely be time-consuming to get used to it
m
yea, but it’s mostly cause that’s how we started. I’m glad they can coexist. the 2020 effort is to begin the migration of some customizations over to 2.0
but the way I organize the code actually saves me some trouble
m
That's a good plan. I've been trying to do that mostly by making all new scripts/projects in 2.0 and only modifying the 1.0 code when they're relatively simple changes.
m
I use something of a modified module pattern so it lets me keep the code really organized. probably my best contribution to the whole project
Copy code
var LPCLV2 = (function () {
    var _job = {
        form: {},
        shipping: {}
    };

    var _log = {};

    return {
        job: _job,
        log: _log
    }
})();
that’s a library function I load called client.namspaces
m
Based on that, you'll probably like 2.0 a lot once you get into it, but it's definitely slow to re-learn all the various functions/methods
m
and then, when I write new features, I just “extend” this object
m
That approach should be right at home with 2.0's general structure
m
Untitled
Untitled
I agree
so that’s a “feature module” that tacks itself onto the parent LPCLV object.
and I “Export” out the “public” methods down at the bottom. That what I end up calling in the script records
so then I can have a single validate function for the whole feature that maps to the various controls. You can see that in the 
Fields
object
I do the same with 
fieldChange
but I refer to them Observers
m
That's definitely much more organized/streamlined than our 1.0 code
In any case, thanks for sharing the 
validateField
workaround, I'll have to give it a shot in some of our code, it seems like a much better option than just clearing the field out
👍🏾 1
m
yea I’ve found this a really good way to organize things. Haven’t had too many side effects. And we just hired our first junior dev and he’s been able to make pretty good sense out of it
no problem. If I run into unanticpated gotchas I’ll be sure to let you know.
👍 1
Open in Slack
PreviousNext
Powered by