* Best practices | In-scripts custom dependancies * Hello team, Are there any best practices with in-script custom dependancies and ideally a way to manage these with SDF? I call "in-script" custom dependancies: the custom fields, custom searches, custom forms, custom roles, etc.... Do you usually use CONST at the beginning of the script? Can we use JSdoc? Other ideas? Thanks.

are you referring to a global object that you can keep referring to? as in ...

const FIELDS = {
    STARTDATE : 'custcol_xx_yyy_startdate,
    ENDDATE : 'custcol_xx_yyy_enddate,
}

Yes that’s one solution :) I’m wondering if there is THE ultime solution to make sure we have all objects include in a SDF project. Ideally, that would be great that the validation does it also, but I don’t think it does.

ctrl-F "cust" ? 😄

That’s another solution 😅

I don't know of a way to automagically do what you're asking, and I low-key hate the above pattern, feels like its just hiding the ids that i need

You don’t like using CONST? What I like with having all the objects at the beginning is that’s easy to see and update. How many scripts are written with custbody22?! 😅

aren't all your dependent objects going to be in your objects folder?!

They should if the project is created from scratch, but when you’re supporting, optimizing, redesigning…

oh no i use a naming convention for custom EVERYTHING... i just don't like creating a constants object that you then use inside the code instead of the actual field ids

An SDF Project's

manifest.xml

file is where you can list any dependencies on Objects that are not defined in your Project. For things like custom lists or fixed internal ID references (e.g. the ID of a specific Vendor or Employee record), I typically create reusable enumeration modules rather than re-defining a

const

in every module where I need it. For custom record/field IDs, I'm with Anthony and don't like to obfuscate them; I prefer to use the literal string references.

Thanks Eric, appreciate it 😅

I personally don’t like using literal string references for field IDs because NetSuite has a history of changing the value of some native fields. I believe they are changing the field IDs of custom segments in the 2023.2 update for example. So it’s best to put those field ID references in a module where you are not having to repeat the same string literal everywhere in your code. Sure you can do Find and Replace in your IDE, but that is prone to human error

I'm not sure I've experienced a native field ID changing. Am I alone in that?

I haven't experienced that either... and I'm pretty sure I'd remember having to go through an entire set of client's codebases finding and replacing native field ids

Well my company got this email from Oracle where they are changing the IDs of custom segments.

you probably got that email because you ARE using custom segments... and possibly also in suite analytics? the fact that they sent an email about it suggests it isn't happening all the time, and I've never seen something like this in 10 years working in NS

Well I’ve seen custom segments used by multiple companies from my experience, so I don’t think this is a rare feature if that is what you are implying. Anyways, that’s not really the point. Ultimately Oracle has the ability to change native field IDs at any point, so for me it’s best to put on string literals of field IDs in some kind of enumerated file or constants directory so that there are less weakpoints to maintain. This is personal preference obviously as I have encountered many senior developers who find that this makes the code unreadable. It does require more imports and I think I read somewhere that NetSuite enforces some kind of limit on what you can import. But I don’t think we are close to reaching that limit.

no no the feature itself isn't rare - I just meant NS changing field ids is rare, this is literally the first time I've seen it

Yeah it shouldn’t happen too often, but I’m not surprised since NetSuite has been around for a while. So they need to update their legacy features at some point

yeah they've done stuff like that with new rollouts, but they usually provide some kind of crutch to make it less painful

I'm one of those very senior developers that considers aliasing the native field names as a worst practice. Fortunately, we use NFT+TS so in general any field name change is a strongly typed refactoring supported confidently by the IDE. A dozen years ago we dabbled with this aliasing approach and it cost much more than it helped.

@Shawn Talbert, do you have some documentations explaining your recommendations, please?

Are you asking to some reasoning to avoid abstracting the actual field names in code?

No need for reasoning 😉 I was thinking maybe some examples of your practice 😇

Oh. Well, here's a bit of example https://github.com/ExploreConsulting/netsuite-fasttrack-toolkit-ss2/blob/master/example.ts

Thanks

I personally don’t use typescript because I am not sure how it is implemented by the third party provider or how often it is maintained. But I do wish Oracle would someday add typescript support for SuiteScript!

I am confident that the TypeScript compiler creates more compliant JS code than I would by hand. Though admittedly, the actual code emitted in SS2.1 is identical to the TS source (sans types) in most cases

I’m sure that headinthecloud has done an amazing job with their typescript support. I am just waiting on if Oracle would ever add their implementation of Typescript. Would rather stick closely with native NetSuite as much as I can personally.

@mrrob503 what do you think? 🙂

In general the HITC typings are more accurate than NetSuite's own documentation.