Autocomplete on String Literals

[JonnyBoy333]

I realize this may be a lofty goal but it would be truly amazing if we could get intellisense on what strings needed to be in specific contexts, like we had in suitescript 1.0 in eclipse. Enums may also be a solution for this, however, there would be a very large number to setup and it would require the user to remember how to invoke all of the different enum declarations. Example:

Typescript Definition:

interface GetSublistValueOptions {
    /** The internal ID of the sublist. */
    sublistId: string | 'items'  | 'expenses' | 'addressbook'; //<--- string literals defined here
    /** The internal ID of a standard or custom sublist field. */
    fieldId: string;
    /** The line number for the field. */
    line: number;
}

Would give you completion like this:

Ideally the string options would be limited to that specific record type so you wouldn't get a sublist like 'expenses' available on a sales order record, for example.

I should also add, if a structure is agreed upon I would be happy to help in filling in the definitions.

[ShawnTalbert]

This would be feasible with NFT-SS2, since it declares a specific class for each record type in NS.

…

On Mon, May 22, 2017 at 12:13 PM JonnyBoy333 ***@***.***> wrote: I realize this may be a lofty goal but it would be truly amazing if we could get intellisense on what strings needed to be in specific contexts, like we had in suitescript 1.0 in eclipse. Enums may also be a solution for this, however, there would need to be a very large number to setup and it would require the user to remember how to invoke all of the enum declarations. Example: Typescript Definition: interface GetSublistValueOptions { /** The internal ID of the sublist. */ sublistId: string | 'items' | 'expenses' | 'addressbook'; //<--- string literals defined here /** The internal ID of a standard or custom sublist field. */ fieldId: string; /** The line number for the field. */ line: number; } Would give you completion like this: [image: autocomplete] <https://cloud.githubusercontent.com/assets/15164008/26324381/2e06a056-3ef8-11e7-9eaa-3357bcb44920.png> Ideally the string options would be limited to that specific record type so you wouldn't get a sublist like 'expenses' available on a sales order record, for example. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#45>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRWg-Ofa4CVrItNzULuR21LwUAx1sGiks5r8d5RgaJpZM4NixAg> .

[johnogle222]

I've been thinking through ways to make this happen - which may be a bit easier now that the SDF CLI tools are out. We would run a script to download all of the customization objects in the system and generate some local type aliases that are utilized through the library.

I haven't really broken much (or really any) ground other than brainstorming some potential paths to proceed down. No proof of concept or anything like that.

If you would like to get started on something I'd be happy to help out wherever I can. Otherwise, as you put it, this is a bit too lofty for what my short term time availability will allow for now. I will get around to it eventually but have some other priorities at the moment.

[JonnyBoy333]

Downloading all customization certainly would be an ideal goal. It might be worth starting with just the default fields before trying to tackle custom fields. Not being an expert at TypeScript I was thinking that the record type could be specified in the context definition

function beforeLoad(ctx: EntryPoints.UserEvent.beforeLoadContext.SalesOrder) {})

Or else it would be cool if you could further define a type when you assign a variable

let rec = <SalesOrder> ctx.newRecord;

[ShawnTalbert]

I actually have plans to create a tool to pull down ALL the customizations in a NS account, generating corresponding NFT-SS2 (TypeScript) classes/enums for them. Default fields are already being defined directly in NFT.

With this, we'll finally have a programming environment in NS near what we had 15 years ago in other programming environments. :\

[JonnyBoy333]

I have been working on trying to accomplish this and have made decent enough progress that it is now worth showing. If you are interested in testing please download my fork here: https://github.com/JonnyBoy333/typings-suitescript-2.0/tree/record-field-definitions

I had three goals when looking at this feature:

1. Autocomplete for every standard NetSuite field you can find in the record browser.
2. Type safety for all standard fields (i.e. if the field is a checkbox it should be recognized as a boolean by typescript).
3. Ability to add custom fields.

What is accomplished so far:

1. Autocomplete on all standard NetSuite fields.

In order to make this work, I have created individual files for each record in NetSuite to capture all the fields and put them in function options that are then imported into the main record file. There is a generator file in the 'helpers' folder that scrapes all the pages of the record browser to create these files which can be run when new versions of the record browser are released to update fields.
Autocomplete on main field strings from the context type:

Autocomplete on sublist strings:

Autocomplete on sublist field strings:

Autocomplete on main fields from a loaded record:

2. Type safety. There is a bug in typescript that prevented me from accomplishing this. The files are all setup to support it from the categorization of the field ID's by field type when the issue is fixed.

The issue is that when you create function options with different resulting types (i.e. boolean, string, etc.) you lose auto-complete on all of the strings, which is a major drawback. The issue has been logged here so please thumbs up: microsoft/TypeScript#17127.

3. Custom fields. It would be fairly simple to add a file to add custom fields and import those into records.. but that doesn't accommodate people like me. That is, people who have this package installed globally and work in multiple NetSuite accounts. I need to come up with a way to include custom fields on a per project basis and import them into this module. If you have any bright ideas let me know.

Note: I did all my working using VSCode as my editor. I did try this in both Atom and Webstorm. Atom handled it ok but the auto complete is not as good as VSCode IMO but Webstorm did not always pick the right auto correct options. So I would really only recommend using this in VSCode.

[ShawnTalbert]

NFT already has this... Perhaps worth considering.

…

On Sat, Aug 5, 2017, 10:32 AM JonnyBoy333 ***@***.***> wrote: I have been working on trying to accomplish this and have made decent enough progress that it is now worth showing. If you are interested in testing please download my fork here: https://github.com/JonnyBoy333/typings-suitescript-2.0/tree/record-field-definitions I had three goals when looking at this feature: 1. Autocomplete for every standard NetSuite field you can find in the record browser. 2. Type safety for all standard fields (i.e. if the field is a checkbox it should be recognized as a boolean by typescript). 3. Ability to add custom fields. What is accomplished so far: 1. Autocomplete on all standard NetSuite fields. In order to make this work, I have created individual files for each record in NetSuite to capture all the fields and put them in function options that are then imported into the main record file. There is a generator file in the 'helpers' folder that scrapes all the pages of the record browser to create these files which can be run when new versions of the record browser are released to update fields. Autocomplete on main field strings from the context type: [image: current_rec_main_field] <https://user-images.githubusercontent.com/15164008/28991139-e04d0d6e-7949-11e7-960c-cc38255ffa39.png> Autocomplete on sublist strings: [image: current_rec_sublist] <https://user-images.githubusercontent.com/15164008/28991149-ff874668-7949-11e7-806c-3e48487300c2.png> Autocomplete on sublist field strings: [image: current_rec_sublist_field] <https://user-images.githubusercontent.com/15164008/28991159-12947d02-794a-11e7-9c60-685f2e94b01c.png> Autocomplete on main fields from a loaded record: [image: loaded_rec_main_fields] <https://user-images.githubusercontent.com/15164008/28991422-cb7dbf02-794c-11e7-8b01-42e63a17f803.png> 1. Type safety. There is a bug in typescript that prevented me from accomplishing this. The files are all setup to support it from the categorization of the field ID's by field type when the issue is fixed. [image: field_types] <https://user-images.githubusercontent.com/15164008/28991362-eaae64a4-794b-11e7-92ef-b9d9d6940234.png> The issue is that when you create function options with different resulting types (i.e. boolean, string, etc.) you lose auto-complete on all of the strings, which is a major drawback. The issue has been logged here so please thumbs up: microsoft/TypeScript#17127 <microsoft/TypeScript#17127>. 1. Custom fields. It would be fairly simple to add a file to add custom fields and import those into records.. *but* that doesn't accommodate people like me. That is, people who have this package installed globally and work in multiple NetSuite accounts. I need to come up with a way to include custom fields on a per project basis and import them into this module. If you have any bright ideas let me know. Note: I did all my working using VSCode as my editor. I did try this in both Atom and Webstorm. Atom handled it ok but the auto complete is not as good as VSCode IMO but Webstorm did not always pick the right auto correct options. So I would really only recommend using this in VSCode. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRWg-v5198OwhZExiWycg9zkE8vt1Bpks5sVKcsgaJpZM4NixAg> .

[JonnyBoy333]

@ShawnTalbert I have looked into NFT, it is quite impressive, adds a lot of useful capabilities. It's a little tricky for me to implement, however, since I'd have to convince the rest of my developer team to start using it and installing it into each of our new accounts, which is a tough sell. It's easier, for now, to just use the typescript library.

Also worth considering, I have support for the field IDs or all 182 records in NetSuite. So whatever record you load, you'll be covered.