This replaces the deprecated JSX compiler formerly provided by
react-tools to use the Babel preprocessor.
This allows us to use ES6+ inside Canvas :)
Unfortunately, we had the jsx pragma hanging around all over the place
and Babel considers this an ERROR now... so I ripped them all out.
Babel also turns on strict mode for JS files, which means I needed
to fix a few things in other places to make it work such as duplicate
object keys and variables without declaration. DueDateTokenWrapper.jsx
had a problem with a 'this' being seen on the global level which Babel
detects to be nothing so it throws in an undefined. I reworked it so
that the function should still have the intended effect and 'this'
is properly scoped.
closes CNVS-24123
Test Plan
- Make sure all JSX compiles via Guard and via js:jsx rake task
- Make sure nothing is broken in any of the react-y areas of
Canvas.
Change-Id: I5ab8f7f435504f8269e2b7da96813337676cf175
Reviewed-on: https://gerrit.instructure.com/65451
Reviewed-by: Benjamin Porter <bporter@instructure.com>
Tested-by: Jenkins
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
before, we only used 'parallel' in asset generation
tasks, now we do it in prod too.
Change-Id: I107b339330173894942ba35f133d7e9602906b7c
Reviewed-on: https://gerrit.instructure.com/58839
Tested-by: Rob Orton <rob@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
what this does:
* Changes the way we generate css so we are able to generate custom
css for people that use the theme editor.
* Sets everything up so we can push all of our static assets
(js, fonts, css, images, etc) to s3 pre-deploy and serve them
from cloudfront. Yay! faster canvas for everyone!
* as part of that, this enables the rails asset pipeline just so we
can use it to put md5s in our urls. we don't use it for any of the
coffeescript/sass/sprockets transformer stuff.
* adds a new "Theme editor" functionality (only for people that have
have the use-new-styles feature flag turned on) where an admin for
an account can pick their own colors/images for all the users
at their account/school.
* when the user is done saving things in theme editor, it will,
in a delayed job, generate all the css with against the variables
that user specified and push it to s3 so it will be available to
anyone else that requests it. (the delayed job will shell
out to a node.js executable called `brandable_css`).
* ability to pick an existing shared theme and to reset to
blank theme. closes: CNVS-19685
* gets rid of jammit.
test plan:
(this is exaustive, so not every person has to do every step
but we should make sure at least someone does each of these things.
maybe as part of the review add a comment if you have done one of these
bulletpoints)
* before you check this out, compile all css and copy the
public/stylsheets_compiled directory somewhere. after you check out
this code and regenerate all the css. make sure there are no
significant changes to the css output. (we updated the versions of
node-sass and autoprefixer that we use so we want to make sure they
don't change things in a way we weren't expecting)
* make sure the way we load css for handlebars templates still works.
eg: if there is a handlebars template at
app/views/jst/some/template.handlebars
if there is also a scss file at
app/stylesheets/jst/some/template.scss
then that stylesheet should get loaded when that template is rendered
* check out the code and run migrations. browse around canvas,
make sure css and js files load correctly as before.
* cody, jacob, or someone on queso: look at the db migrations and
make sure everything looks good and that I am handling sharding
correctly.
* verify that both rake canvas:compile_assets and guard, works as well
as `node_modules/.bin/brandable_css` (note: if you have
"node_modules/.bin" in your PATH (which you should), it will also
work with just `brandable_css`)
* verify that passing the --watch option to
`.bin/node_modules/brandable_css` works and picks up changes to
sass files, images, fonts, or any other resource that goes into
a css file. and that it only recompiles the css files that actually
depend on that file.
* go to https://github.com/ryankshaw/brandable_css and check out the
code there. that is what is actually doing the sass compiling
* create a config/canvas_cdn.yml file and add aws access creds and
an s3 bucket and cdn hostname (for testing, you can use the credentials
for instructure_uploads_engineering from
https://gollum.instructure.com/OtherServiceTestAccounts ). for a test
cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that
is a cloudfront bucket I set up on my personal account that points to
instructure_uploads_engineering
* run rake canvas:compile_assets again, this time, at the end, you
should see it run the assets:precompile task that puts md5s in filenames
and, gzipps them, and copys them to public/assets.
then you should see it run canvas:cdn:upload_to_s3
(look at log/development.log for progress),
which pushes everything to s3.
closes: CNVS-17333 CNVS-17430 CNVS-17337
* try out the theme editor: turn on new styles, go to accounts/x
(where x is the @domain root acount you are testing from) and click
the "theme editor" button on the right side of the page.
that should take you to a page that has the ability to pick colors/images
on the left side and preview your changes in an iframe on the right
closes: CNVS-19360 CNVS-20551
* test the "preview", "save", "reset", and "choose existing" functionality
closes: CNVS-17339 CNVS-17338 CNVS-19685
* make sure that the themeeditor works both if you have
config/canvas_cdn.yml set up and enabled as well as if you don't.
if it is enabled, you should see it push the css for just that new
brand config to s3 when you hit preview, and the css
should be accessible from the cdn you configured.
Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22
Reviewed-on: https://gerrit.instructure.com/53873
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Replaces the PostGradesModel and PostGradesDialog with functional
ReactJS code.
- more visual feedback for users during correction step:
- green check mark when whole row/assignment is good
- uses an "ignore" (minus) icon instead of an X
- rows stay on page, even after corrected (allowing
users to correct any mistakes during data entry)
- when name is not unique a visual hint is shown:
"The assignment name must be unique"
- "Ignore All" button is now "Ignore These" since it
pertains to uncorrected rows, rather than all rows
- "Ignore All" button becomes "Continue" button after
all corrections have been made
- calendar datepicker no longer freezes / has issues
- when the user has fixed all assignments with errors,
the title becomes: "No Assignments with Errors, click
Continue"
- if the user ignores a single assignment (with the
minus "-" button) he/she can restore the assignment
by editing the assignment name or due date
- corrected assignments (names, due dates) are now saved
all at once when the user presses "Continue" (or "Ignore
These" if he/she wants to ignore remaining issues)
- the gradebook "Post Grades" button that opens the dialog:
- appears when selecting a section with an SIS ID, and
disappears when the section has no SIS ID
- is now styled like other buttons
- when closing the dialog and re-opening, the dialog
returns to the "correction" step
- ungraded submissions message on the summary page if
one or more students have submitted work but the teacher
has not yet graded it
- clicking the ungraded submissions message/link takes
the user to a screen showing ungraded submissions
that are clickable (takes the user to speedgrader)
Fixes SIS-646
Fixes SIS-654
Change-Id: I464fc85a3b96e5051bdad078e4483d979cfaf3e0
Reviewed-on: https://gerrit.instructure.com/44491
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ken Romney <kromney@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cosme Salazar <cosme@instructure.com>
test plan:
with guard running:
edit a handlebars file that has a corresponding
sass file.
e.g.: app/views/jst/FolderTreeItem.handlebars
it should not crash guard
Change-Id: Icd04510dc4ac0ff80674d1b3116da0dccb199fd9
Reviewed-on: https://gerrit.instructure.com/41019
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
after many steps towards this moment, we're finally here
This yanks sass and compass out of canvas-lms
completely and instead uses the libsass based
node-sass to compile our SASS files.
wins:
It is WAYYY faster!
as in, < 10 seconds to recompile all css in canvas
(compared to the 5+ minutes it used to take)
It is all in JS, helping use move to a completely
nodeJS based fronted tooling workflow.
next steps:
remove jammit: we don't need an assets.yml file
since node-sass can output compressed css for us
and we use sass to do all of our @import'ing of other
files (@colleen calls those "compiler" sheets), this
would simplify and speed up fronted asset building
even more
use gulp/broccoli/whatev to do cached, incremental builds
test plan:
all outputted css should look exactly the
same as it used to.
run `npm run compile-sass`, make sure it works
and is way faster than `rake css:generate` used to be
Change-Id: I7d865ea6b3e374cdc27a883d2019a4c15746c0e2
Reviewed-on: https://gerrit.instructure.com/38416
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
since you run guard in development, you want
to see the line # comments and nicely formatted
output
test plan:
* run guard, hit enter
all of generated css should be nicely formatedd
and have line # comments in it
Change-Id: I7c5badcc83d363efb82461c9e2d187f153fc8c73
Reviewed-on: https://gerrit.instructure.com/34943
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes CNVS-11426
The UI/UX team *really* wants to start doing some major style changes
to the canvas interface. Because it is a very visual change and especially
because we've let people hack the crap out of canvas styles with
their own css override file, any changes we do need to be behind a
feature flag so an institution can opt-in when they are ready.
This commit does some trickery so we actually create 4 different versions
of every stylesheet. one for each variant in:
legacy_normal_contrast legacy_high_contrast
new_styles_normal_contrast new_styles_high_contrast
and then sets the $use_new_styles and $use_high_contrast sass variables
accordingly in each.
now, in any sass file, you can do things like:
@if $use_new_styles {
background-color: red;
} @else {
background-color: blue;
}
@if not $use_high_contrast{
font-size: 12px;
}
test plan:
* in a production (minified assets) environment, ensure you see:
<link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page
* go to the account settings page for the domain_root_account you are on
* turn on the "Use New Styles" feature
* now verify that <link href="/assets/common_new_styles_normal_contrast.css...
is in the <head>. There should not be any visible differences because we do
not have any styles that target specifically $use_new_styles yet.
* now, go to /settings and turn on the user feature for "Use High Contrast Styles"
* verify that <link href="/assets/common_new_styles_high_contrast.css..
is in the <head>
* again, turning that on will not actually change the way anything looks,
the next commit (g/32863) will take care of that
Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418
Reviewed-on: https://gerrit.instructure.com/31881
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
fixes CNVS-11640
test plan:
* start guard
* introduce a syntax error in a handlebars file
* verify that the error is displayed
Change-Id: I17f624a709c96dfbd9114b4c7204c8bec51cd425
Reviewed-on: https://gerrit.instructure.com/31340
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Braden Anderson <banderson@instructure.com>
closes CNVS-10038
test plan:
- run bundle exec guard from canvas root
- edit a ember handlebars template with an error and save
- watch guard window, will display error
- fix template and save
- guard should compile successfully
Change-Id: I3ab589b8d6c2c8b059b394e83be0d26fbd5186cd
Reviewed-on: https://gerrit.instructure.com/27583
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
QA-Review: Jason Madsen <jmadsen@instructure.com>
Product-Review: Jason Madsen <jmadsen@instructure.com>
test plan:
1. put some invalid sass in a jst stylesheet
2. you should see the error in the guard output, but guard shouldn't die
Change-Id: Idd07ba3c64f89d35e79e3f6a886a28a26f8e8a1c
Reviewed-on: https://gerrit.instructure.com/24557
Reviewed-by: Mark Ericksen <marke@instructure.com>
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
now when you update or delete a jst s[ac]ss file:
1. guard recompiles (or deletes) the css (don't need to wait for compass
middleware)
2. guard recompiles the corresponding .handlebars so that it has the
correct embedded css
test plan:
it should no longer be ridiculously painful to use jst css files. in other
words, change your file, refresh the page, voila!
Change-Id: I61e245dc827fd5006cc7cd0af4e074bb8c5108cc
Reviewed-on: https://gerrit.instructure.com/24459
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
- added new ember application generator
- also Ember -> ember in AMD requires
Change-Id: I7914a2578161e4f8370fc05ed6596ed07347c897
Reviewed-on: https://gerrit.instructure.com/24038
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
This commit adds ember.js (http://emberjs.com)
libraries to canvas.
Ember apps can be created by
adding a directory to 'app/coffeescripts/ember',
e.g. 'app/coffeescripts/ember/inbox/'
Shared Code
-----------
'app/coffeescripts/ember/shared', contains shared
resources between ember apps.
'shared/helpers/common' is included in all ember
templates.
Tooling
-------
- Bundles will be auto-generated by file system
naming conventions, see lib/ember_bundle and its
specs for details.
- Guard will precompile templates and create the
bundle file when files are changed
- Rake tasks added for deployment `jet:ember` and
`js:bundle_ember_apps`
Change-Id: I6d4177891cb618d5dbff3c87553fbf448e91393b
Reviewed-on: https://gerrit.instructure.com/22688
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
use correct method name so guard doesn't die when a handlebars template is
removed
test plan:
1. start guard
2. create a handlebars template
3. confirm the .js file gets created
4. delete the template
5. confirm the .js file gets deleted
6. guard should not asplode
Change-Id: I58456ef9d7d4a9bdaffb8d61d39d7e22c42d8d1a
Reviewed-on: https://gerrit.instructure.com/20605
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Stanley Stuart <stanley@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
also remove the need for Guardfile within plugins (and stop including
them)
note that guard still can't detect changes to files in symlinked plugins
on the mac (due to fsevent), though you can hit enter to recompile everything
test plan:
1. clone a plugin into vendor/plugins
2. start up guard
3. edit a coffee file in the plugin
4. guard should detect it and compile it in the right place
5. edit a coffee spec file in the plugin
6. guard should detect it and compile it in the right place
7. edit a handlebars file in the plugin
8. guard should detect it and compile it in the right place
9. hit enter
10. guard should compile all coffee/handlebars files in the right place
Change-Id: I1e7c12f1368af66dee024e258899412526bb3fd2
Reviewed-on: https://gerrit.instructure.com/20219
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
actually delete compiled templates when run_on_deletion runs, rather than
firing the JST guard. now guard won't be sad when you delete a handlebars
template (e.g. if you change branches)
test plan:
1. `bundle exec guard`
2. `touch app/views/jst/poo.handlebars`
confirm that public/javascripts/jst/poo.js gets created
3. `rm app/views/jst/poo.handlebars`
confirm that public/javascripts/jst/poo.js gets deleted
Change-Id: Ic11a519d946e130ab2ca3202662efdf7ecdbf6b0
Reviewed-on: https://gerrit.instructure.com/20143
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Stanley Stuart <stanley@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
given app/coffeescripts/foo.coffee in canvas-lms, if you want to monkey
patch it from your plugin, create app/coffeescripts/extensions/foo.coffee
(in your plugin) like so:
define ->
(Foo) ->
Foo::zomg = -> "i added this method"
Foo
and that's it, no changes required in canvas-lms, no plugin bundles, etc.
note that Foo is not an explicit dependency, it magically figures it out.
also note that your module should return a function that returns Foo.
this function will magically wrap around Foo so you can do stuff to it
anytime somebody requires "foo" as per usual.
test plan:
1. use it as explained above
2. it should work
Change-Id: If3b21782c0e79bb0ce55b4f16804047a2c2e2143
Reviewed-on: https://gerrit.instructure.com/20004
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
1. start guard
2. save a file in app/stylesheets
- styleguide should be created (guard will
tell you)
3. hit enter
- styleguide should be created
Change-Id: I891a906602b6df0f964f2e502f124f5d05b4b796
Reviewed-on: https://gerrit.instructure.com/19525
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
test plan:
- make sure you have the coffee binary from npm:
`npm install -g coffee-script@1.6.2`
- run rake js:generate, make sure all coffeescript still compiles
correctly
- open a coffeescript file and make sure it still gets automatically
compiled when saved by guard.
- rejoice at the arrival of source maps.
Change-Id: I06ce9e83a76be9d4cc0e2b2c80566a0db19f9d7e
Reviewed-on: https://gerrit.instructure.com/18842
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
a faster rake js:generate, js:build, canvas:compile_assets, and guard
will use 'coffee' binary if installed
even if it doesn't use 'coffee' binary it will be
a lot faster
`time rake js:generate`
before => real 0m29.960s
with 'coffee' binary => real 0m4.342s
without => real 0m8.202s
test plan:
* run bundle exec guard; ensure coffeescripts are compiled to the
correct directories
* run rake js:generate; ditto
Change-Id: I8fc4d4a415e5c77d1efa910c0922588d3095446b
Reviewed-on: https://gerrit.instructure.com/9989
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
test plan:
* checkout patchset 1 from https://gerrit.instructure.com/7469
* symlink the canvalytics repo into vendor/plugins/
* symlink public/plugins/canvalytics to vendor/plugins/canvalytics/public/
* run guard, regenerate all files
* make sure the route /analytics/course/<id>/user/<id> renders handlebars
unit tests not provided for this scaffolding stuff
Change-Id: Ibf626555cbb79a5a97d67286ef4a7d8f28f53de8
Reviewed-on: https://gerrit.instructure.com/7470
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
couldn't actually get the run_on_deletion method working
but if you start guard and hit enter in that terminal window
it will delete the entire public/javascripts/jst directory
and re compile all
Change-Id: I25df0bc2cc0031c61e32c0141cef7d3f688a1056
Reviewed-on: https://gerrit.instructure.com/6171
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
- New rake task `rake jst:compile` to precompile
JavaScript templates into functions.
Add handlebars templates to app/views/jst and
they'll get compiled to public/javascripts/jst
- New rake task `rake jasmine` and `jasmine:ci` to
run JavaScript specs.
Add specs to spec/coffeescripts and they'll get
compiled into spec/javascripts
- Added Guard gem `$ guard` that watches
coffeescript and handlebars files and compiles
them when changes are made.
- Created Handlebars Ruby class that precompiles
the templates into JavaScript functions
- Added JS Template constructor to abstract
our tempting API
Change-Id: Ie993d0fc50d49b161ed94dbc066c4475cefdc427
Reviewed-on: https://gerrit.instructure.com/5813
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>