Run on local webserver AND still deploy as app script?

[enuchi]

Run on local webserver AND still deploy as app script?

[enuchi]

Yes. Others are asking (#32) and I'm working on a fully functioning version to include with this repo.

For now if you want the quick version so you can work locally, you need to install webpack-dev-server, which is what Create React App uses. Just run these commands:

1. Install webpack dev server: npm i -D webpack-dev-server
2. Run webpack dev server: npx webpack-dev-server --mode development --port 8080
3. Open the page you're working on in the browser: http://localhost:8080/about.html

Couple of notes:

• Hot reloading should work. Just save your code changes and the page will reload.
• As you said, you'll need to mock any server responses. If you actually try to call the server you'll get a google is not defined error in the browser. http://localhost:8080/main.html in my example app won't load since it calls the server, but about.html.
• Your page will take up the full screen, so you may want to wrap it in a container that's the size of your dialog/sidebar to see what it will actually look like.

I have a solution on how to run your local code inside an actual google dialog/sidebar, and call the actual server functions. It works really well, it's just pretty complicated and needs cleaning up. Will post here when I have a version you can try out.

[jedgrant]

FANTASTIC! :) Thanks so much for the work you're doing.

[enuchi]

Hey @nikola3244 thanks for this. Yes, think you're right. Haven't tried your steps yet but for now can you try putting the -impl files in .claspignore?

Something like this (don't know exact syntax off hand but you can reference https://github.com/google/clasp#ignore-file-claspignore if needed):

*-impl.html
**/*-impl.html

[kickbox]

Hi @enuchi , curious to know about the solution you are using to run locally. Is it a mock using gas-mock-globals or similar? or does it literally run actual App Script server code on local?

[nikola3244]

@enuchi You rock! It works perfectly

Just noticed that main.js is also excluded from pushing, so total size for pushing is now just 53.5KB (with the example files in my previous reply), and it appears to be working correctly, i.e. edits are instantly reflected in the addon.

[enuchi]

Yup, Material UI is a big library so makes sense not to import the whole thing if your bundles are still small.

Thanks for the PR, it's merged.

[kickbox]

Hi @enuchi , finally local dev is working on my new setup!! Thanks a ton! claspignore did the trick.

[enuchi]

Hi @jedgrant @kickbox , wanted to let you know that I've done a major update for the repo with support for local development. The development setup allows you to actually run your app locally and see it inside the google dialog window, while being able to access server code. It supports hot reloading for the react app. This should be a MUCH better development experience. If you get a chance please let me know if the new setup works for you.

[kickbox]

Hi @enuchi , I just upgraded my project setup to the latest version of this repo to test live local development.

1. Everything works as intended in Production mode.

2. However in Development mode
   2.1. I am not able to push code. Push takes very a long time and starts printing parts of the code in terminal, then clasp finally fails with this error. This issue existed even before upgrading to the latest version of this repo. I dont mind this error now.
   
   However after changing mode to production inside clientConfig in webpack.config.js, this error disappears.

   2.2. The pressing issue is, I am unable to call server functions like this serverFunctions.getSheetNames() from frontend. I get the following error: Uncaught TypeError: ew.getSheetNames is not a function. I checked the envrionment setup in webpack.config multiple times and everything seems fine.

Could you please point me in the right direction to resolve 2.2, I am stuck and really want to work with the live local development mode.

[enuchi]

Hi @kickbox, there were a lot of changes in the latest version. If you start with a fresh clone are you able to get the development mode working?

[nikola3244]

Hey, for 2.1 that @kickbox mentioned, the problem is with the file size: for some reason the development build creates huge files and then tries to push them to Google which fails (as an example, the project that I'm working on has just two main files with several components and is about 40MB when compiled in development mode (npm run start), while production mode (npm run deploy) compiles it to just 0.9MB). That does not happen with a fresh repo clone.

@enuchi Funny thing is, the larger code can work if npm run start is done with a smaller codebase and then the code is added locally without running npm run start again, so that makes me think that there is a bug with compiling "large" codebases. ("large" is in quotes because they are not that large at all). I.e. I've cloned the fresh repo, did npm run start, total size of dist/ is 0.3MB (I've also added all of the node dependencies required for the following jsx file). I've then added a simple static jsx file from the project I'm working on, and the changes successfully appeared in the addon. I've then stopped the server, ran npm run start again, and the size of dist/ jumped to 25MB and clasp couldn't push it to Google. The biggest files are main.js with 12.5MB and the offending -impl.html with 12.5MB. The rest of the files are only 289KB total.

Just to give feedback for 2.2 as well: Server functions have been working perfectly for me, both in development and production.

[enuchi]

Hey @nikola3244, thanks for the details. If you have a public repo you can share would be happy to take a look. Or can you provide more info on the files you added or steps to reproduce? If you are adding external packages, the size can get large because all packages are bundled into one file -- -impl.html in production and the regular .html file in development. In development there is no minification so I can see that contributing to the large bundle. Which packages are you adding, if any?

[nikola3244]

Hey @enuchi thanks for the quick reply, I unfortunately cannot share the project, company policies, but I am very willing to help with this issue, since development is not as fast as with live view.

The packages that are being added (to regular deps, not devDeps):

    "@date-io/date-fns": "^1.3.13",
    "@material-ui/core": "^4.11.0",
    "@material-ui/icons": "^4.9.1",
    "@material-ui/lab": "^4.0.0-alpha.56",
    "@material-ui/pickers": "^3.2.10",
    "date-fns": "^2.16.0",

Steps to reproduce:

1. Clone and setup the repo from scratch
2. Add the packages mentioned above
3. Unzip the test-page.zip in src/client/test-page/
4. Define the new page in /webpack.config.js + menu in /src/server/ui.js
5. Run npm run start, and see the dist/ size jump to 25MB

That all seems normal, right? File size goes up since it's not minified etc, but try this now:

1. Clone and setup the repo from scratch
2. Add the packages mentioned above
3. Run npm run start without editing or adding anything
4. Do not stop the server
5. Replace the contents of files in /client/sidebar-about-page with the files from test-page.zip from above
6. Go back to the open sheet tab, and see the new changes

That makes me think that all of the extra code is not needed to be pushed to Google for it to work, since new changes work even with the initial, small, /dist directory. I don't really know how it all works with the live view, but can it be configured so just the server side functions + the web server related code is pushed while all of the compiled stuff is served from local during development?
I assume that this is what already gets pushed with the second scenario from above: server side functions + web server viewer + compiled example sidebar/dialog pages = small file size, with all new big changes are being served locally

[enuchi]

Great! I will open a PR soon to add the -impl files to .claspignore, unless you would like to contribute it.

Also, just a note that the way this package works is by bundling everything into a single file. For large external packages this can add a lot in size to the overall bundle, even when minified in production. A better way is to load packages from a CDN, which will reduce the size of the file significantly, and also allow your users' browser to cache the package.

Using a CDN for your packages is not so straightforward, so that's why I added the working bootstrap example, added some instructions in the readme, and also some notes here in the webpack config:

React-Google-Apps-Script/webpack.config.js

Lines 143 to 176 in ad59879

	// DynamicCdnWebpackPlugin settings
	// these settings help us load 'react', 'react-dom' and the packages defined below from a CDN
	// see https://github.com/enuchi/React-Google-Apps-Script#adding-new-libraries-and-packages
	const DynamicCdnWebpackPluginConfig = {
	// set "verbose" to true to print console logs on CDN usage while webpack builds
	verbose: false,
	resolver: (packageName, packageVersion, options) => {
	const packageSuffix = isProd ? '.min.js' : '.js';
	const moduleDetails = moduleToCdn(packageName, packageVersion, options);
	if (moduleDetails) {
	return moduleDetails;
	}
	// "name" should match the package being imported
	// "var" is important to get right -- this should be the exposed global. Look up "webpack externals" for info.
	switch (packageName) {
	case 'react-transition-group':
	return {
	name: packageName,
	var: 'ReactTransitionGroup',
	version: packageVersion,
	url: `https://unpkg.com/react-transition-group@${packageVersion}/dist/react-transition-group${packageSuffix}`,
	};
	case 'react-bootstrap':
	return {
	name: packageName,
	var: 'ReactBootstrap',
	version: packageVersion,
	url: `https://unpkg.com/react-bootstrap@${packageVersion}/dist/react-bootstrap${packageSuffix}`,
	};
	default:
	return null;
	}
	},
	};

. But I get that it's still not that simple. I may end up adding a Material UI example since a lot of people like that package.

[nikola3244]

Thanks! I've created the PR.

The CDN suggestion is a good one, thanks, but I haven't went down that rabbit hole because of the warnings on Material UI's official site, which seemed reasonable, at least for this package: https://material-ui.com/getting-started/installation/#cdn

Also, I wasn't sure how my IDE (PhpStorm) would handle code suggestions etc if I haven't used a "native" Node package.

[enuchi]

@kickbox are you still having any issues with local development?

[enuchi]

Great. I'll close this issue then.