Oh my global object!

54 views
Skip to first unread message

Alex

unread,
Mar 8, 2020, 2:19:23 PM3/8/20
to Google Apps Script Community
Hi!

I dont like sequences and queues. I'm also not very good at js coding. You must correct me if the next idea looks or does something wrong.

Point 1

We no longer trust loading into the context of the entire project in V8

Point 2

We have to use bundlers for correct loading. The main candidates are Webpack and TypeScript.

Bundlers have a flaw. They don't reverse deployment to developer code. This means that you cannot turn a bundler into code without an external version control system (git as standart).

Point 3

Instead bundlers we can use the singleton pattern (as you know modules aren't supported too)

Suggestion


/**
 *
 */

class App {
 
/**
   *
   */

  constructor
() {
   
if (!App._instance) {
     
this.data = {
        someValue
: 1,
     
};
     
App._instance = this;
   
}
   
return App._instance;
 
}
 
/**
   *
   * @param {*} e
   */

  onOpen
(e) {
   
const f = Object.assign({}, e);
    f
.someValue = this.data.someValue;
    console
.log(f);
 
}
 
/**
   *
   * @param {*} e
   */

  onEdit
(e) {
    console
.log(e);
 
}
}

I use the App class to centralize the business logic of the application.
If I need to use the features of other classes, then I can copy them without changing.
The restrictions on this class are as follows:
  • singleton
  • only business logic
  • determine the properties of the application at startup
Any suggestions and criticism are welcome.

CBM Services

unread,
Mar 8, 2020, 2:49:25 PM3/8/20
to google-apps-sc...@googlegroups.com
Thanks for sharing Alex. It would be also good to expand this with data instances for each using properties.

Care to publish new sample with your suggestion for that?

From: Alex
Sent: ‎2020-‎03-‎08 11:19 AM
To: Google Apps Script Community
Subject: [Apps-Script] Oh my global object!

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/d4a948c4-ebf8-4197-9d83-f072e8030288%40googlegroups.com.

Alex

unread,
Mar 8, 2020, 3:35:15 PM3/8/20
to Google Apps Script Community
Of course!

But it seems to me that I'm missing some important thing. My application does not collapse on its own. I think some kind of closure is needed to initialize the permanent settings.

Now I'm testing this on one addon. I need some applications to understand how appropriate it. For example, error handling can be quite confusing when initializing an App class.

Best
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-community+unsub...@googlegroups.com.

CBMServices Web

unread,
Mar 8, 2020, 3:43:01 PM3/8/20
to google-apps-sc...@googlegroups.com
Yes, on creation of the object, it needs to define the data parms. It will also need methods for changing property values.

I am sure people will want to add business logic as part of parm value changes, but can leave that outside the class.


To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/b46f0211-1f9e-4d37-ac71-471cb7d16ac0%40googlegroups.com.

Adam Morris

unread,
Mar 9, 2020, 10:18:52 AM3/9/20
to Google Apps Script Community
I really like the following pattern which still allows you define stuff in the global scope as normal. It would make more sense to have the Utils class here be implemented as a singleton (although in this example is too trivial to see much of a point to it) rather than the App class, as Utils would potentially be called several times throughout the application's lifecycle.

// App.js
class App {
    constructor () {
         // set up application state
    }

    get utils () {
        return new Utils();
    }
}

// Utils.js
class Utils {
   doSomething () { 
      return 'Hello';
   }
}

// Business.js

function endpoint () {
   const app = App();
   app.utils.doSomething();   
Reply all
Reply to author
Forward
0 new messages