Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Grunt to compress SMap js files. #1533

Merged
merged 1 commit into from
Jun 3, 2017

Conversation

linzjax
Copy link
Contributor

@linzjax linzjax commented May 24, 2017

[NOTE: Not going into master]

Proposed changes in this pull request

  • Addresses SMAP: Implement frontend toolchain #1244
  • setup vagrant provisioning to include grunt.
  • Added gruntserver file to run with ./runserver.
  • Setup Gruntfile.js to uglify SMap files as a test
  • Sorted third party library files into vendor folders
  • Renamed router/routes/router_mixins to SimpleRouter, CreateRoutes, and RouterMixins respectively.
  • put datatable and parsley files into their own folders
  • added jshint to grunt configuration
  • removed all es6 logic from js files and linting.

When should this PR be merged

  • Before SMap is put up on staging.

Risks

  • I'm adding a step to VM set up, as well as a step to deployment. grunt production should be run before deploying to demo/prod. grunt concat should be run when deploying to staging.

Follow-up actions

  • Double check with adri that this actually works.

Checklist (for reviewing)

General

  • Is this PR explained thoroughly? All code changes must be accounted for in the PR description.
  • Is the PR labeled correctly? It should have the migration label if a new migration is added.
  • Is the risk level assessment sufficient? The risks section should contain all risks that might be introduced with the PR and which actions we need to take to mitigate these risks. Possible risks are database migrations, new libraries that need to be installed or changes to deployment scripts.

Functionality

  • Are all requirements met? Compare implemented functionality with the requirements specification.
  • Does the UI work as expected? There should be no Javascript errors in the console; all resources should load. There should be no unexpected errors. Deliberately try to break the feature to find out if there are corner cases that are not handled.

Code

  • Do you fully understand the introduced changes to the code? If not ask for clarification, it might uncover ways to solve a problem in a more elegant and efficient way.
  • Does the PR introduce any inefficient database requests? Use the debug server to check for duplicate requests.
  • Are all necessary strings marked for translation? All strings that are exposed to users via the UI must be marked for translation.

Tests

  • Are there sufficient test cases? Ensure that all components are tested individually; models, forms, and serializers should be tested in isolation even if a test for a view covers these components.
  • If this is a bug fix, are tests for the issue in place? There must be a test case for the bug to ensure the issue won’t regress. Make sure that the tests break without the new code to fix the issue.
  • If this is a new feature or a significant change to an existing feature? has the manual testing spreadsheet been updated with instructions for manual testing?

Security

  • Confirm this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.
  • Are all UI and API inputs run through forms or serializers?
  • Are all external inputs validated and sanitized appropriately?
  • Does all branching logic have a default case?
  • Does this solution handle outliers and edge cases gracefully?
  • Are all external communications secured and restricted to SSL?

Documentation

  • Are changes to the UI documented in the platform docs? If this PR introduces new platform site functionality or changes existing ones, the changes must be documented in the Cadasta Platform Documentation.
  • Are changes to the API documented in the API docs? If this PR introduces new API functionality or changes existing ones, the changes must be documented in the API docs.
  • Are reusable components documented? If this PR introduces components that are relevant to other developers (for instance a mixin for a view or a generic form) they should be documented in the Wiki.

Copy link
Member

@oliverroick oliverroick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really good work. Thanks for cleaning up the JS mess and for adding comments to the files...

I still had a few things to moan about though. See below...

Gruntfile.js Outdated

grunt.registerTask('default', ['concat']);
grunt.registerTask('runserver', ['concat', 'watch']);
grunt.registerTask('production', ['concat', 'uglify', 'jshint']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think running jshint on production is too late. Is there a way to run it on the development server? We can also make it a mandatory test on Travis, but that's a separate task.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. I'll add it to the default grunt command (there are two errors currently, and it short circuits "watch").

Gruntfile.js Outdated
grunt.loadNpmTasks('grunt-contrib-watch');

grunt.registerTask('default', ['concat']);
grunt.registerTask('runserver', ['concat', 'watch']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should run uglify on dev as well and configure a source map. Currently, when an error happens on dev, I can see the code but it's difficult to tell where it happened because I can only look at the concatenated code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's amazing... I was wondering how that worked.

import atexit
import signal

from django.contrib.staticfiles.management.commands.runserver import Command\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, this is ugly. I'd write it like:

from django.contrib.staticfiles.management.commands import runserver

class Command(runserver.Command):

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

const relId = target.attr('data-id');
target.closest('tbody').find('tr.info').removeClass('info');
target.addClass('info');
$('input[name="id"]').val(relId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works but I don't understand how. We must set the party ID somewhere. Where does this happen? ... just curious.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, weirdly enough, I looked around and I'm not sure. I believe this was implemented before we added in select2, and now select2 handles it. I couldn't find anywhere in the code that had a table with a select-list id.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess we'll find out when it's on staging then ;)

become: yes
become_user: root
file: path=/vagrant/node_modules src=/vagrant/cadasta/core/node_modules state=link follow=yes
# when: node_check.stat.exists == False
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check back with @amplifi what this does and whether we need it here? If we don't need it then just remove it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the comment.

@linzjax linzjax force-pushed the feature/map-spa-router-grunt-2 branch from 04572e4 to 3d9f22a Compare May 30, 2017 19:17
- setup vagrant provisioning to include grunt.
- Added gruntserver file to run with ./runserver.
- Setup Gruntfile.js to uglify SMap files as a test
- Sorted third party library files into vendor folders
- put datatable and parsley files into their own folders
- removed all es6 logic from js files
- added jshint to grunt configuration
- added source mapping from uglified files to originals
@linzjax linzjax force-pushed the feature/map-spa-router-grunt-2 branch from 3d9f22a to 13253f9 Compare May 31, 2017 16:09
@linzjax linzjax requested a review from amplifi May 31, 2017 16:10
Copy link
Member

@oliverroick oliverroick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good!

@linzjax linzjax merged commit 65c0d64 into feature/map-spa-router Jun 3, 2017
@linzjax linzjax deleted the feature/map-spa-router-grunt-2 branch June 3, 2017 15:43
linzjax added a commit that referenced this pull request Jun 5, 2017
- setup vagrant provisioning to include grunt.
- Added gruntserver file to run with ./runserver.
- Setup Gruntfile.js to uglify SMap files as a test
- Sorted third party library files into vendor folders
- put datatable and parsley files into their own folders
- removed all es6 logic from js files
- added jshint to grunt configuration
- added source mapping from uglified files to originals
linzjax added a commit that referenced this pull request Jun 13, 2017
- setup vagrant provisioning to include grunt.
- Added gruntserver file to run with ./runserver.
- Setup Gruntfile.js to uglify SMap files as a test
- Sorted third party library files into vendor folders
- put datatable and parsley files into their own folders
- removed all es6 logic from js files
- added jshint to grunt configuration
- added source mapping from uglified files to originals
linzjax added a commit that referenced this pull request Jun 19, 2017
- setup vagrant provisioning to include grunt.
- Added gruntserver file to run with ./runserver.
- Setup Gruntfile.js to uglify SMap files as a test
- Sorted third party library files into vendor folders
- put datatable and parsley files into their own folders
- removed all es6 logic from js files
- added jshint to grunt configuration
- added source mapping from uglified files to originals
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants