The props.tag default was set directly on props,
but the component used it from props.data.tag,
hence the default was ineffective.
Since empty arrays for props.data override nested React defaults,
there's no built-in way to enforce this default.
Hardcoding a default felt viable here, since the component allows overrides via props.
We can't use our own "id" values here, since react-bootstrap requires internal consistency
between tab containers and tab panes through its own auto-generated identifiers
This doesn’t have much impact on resulting JS size, but it will
hopefully make merge conflicts much less frequent.
The CSS growth is a little higher (6.5% increase in size) but is not
material.
If this materially reduces the number of merge conflicts we have, by
letting the git merge tools resolve some dist file mergers, I think it
would be worth it.
Some example changes in file size:
bundle.js 290K -> 301K
vendor.js 1,325K -> 1,321K
bundle.css 628K -> 669K
* Rename bundles (prep for webpack optimisation)
This might or might not reduce the overall repo size,
because git can combine similar chunks in the newly generated files
* Optimise webpack build time
Consolidates bundles, since a separation of bundle-framework.js vs. bundle-legacy.js
vs. bundle-lib.js no longer makes sense - they're all loaded upfront anyway,
since we'll be introducing more react-powered logic alongside the "legacy" JavaScript.
By consolidating into fewer bundles, we give the optimisation scripts (UglifyJS)
more options to reduce the overall file size.
The main motivation for a vendor.js is to shorten rebuild times:
Most active development is happening in files required through bundle.js.
This commit drastically reduces the rebuild time for those changes (15s to 4s).
* Panel/tab-panel and alerts spacing, button padding consistency and alignment
* Reports panel spacing adjustments
* ReportAdmin panel and toolbar spacing
* Comment change
* Fix formatting help toggle link
* Use standard line-heights and padding for buttons
* Add base panel styles
* Update to .panel styles and .toolbar spacing
* Remove legacy styles, linting fixes
* Toolbar--content to have consistent styles throughout
* Add panel and toolbar styles to areas missing them
* Replace values with variables
* Layout overrides for tabs and panels with padding
* Adjust JQueryUI button spacing to match other UI buttons
* Remove custom ReportAdmin styles
Update values to variables and modify panel and tab-panel spacing
* Remove text color override
* Remove double (.m-t-1) spacing from campaign panel
* Profile page remove legacy JLayout
* Remove legacy spacing
* Removed Layout from page so !important not needed
* Improve use of variables
* Add missing closing bracket, minor linting fixes
* Linting fixes
* Remove css importants
* Add temp fix for file upload within gridfield
Tidy structure of css
* css build
* Spacing bug fixed for campaign list alert
* Added Created field to File/Image editor
* switch default input value to null
Fix react errors and added a field description
* API Use new DBField::getSchemaValue()
The ‘npm run lint’ command will be used to run listing on Travis, which
can also be used on local dev environments. These can also be used with
editor plugins to highlight errors immediately.
The intention is that this can be used in place of codeclimate. The
benefits are that we use a single toolchain in both CI and local dev,
which is not entirely the case at the moment.
Note the sass-lint is provided by “sudo gem install scss_lint”. It’s
possible that we can move to a node-based sass-lint; I can’t recall
what the motivation for using the scss_lint gem was - I think it was
mainly that we had the AirBNB styleguide already implemented as a linter
config.
When rewriting the i18n.js file from ES5 to ES6, the detectLocale()
call in the constructor was missed - meaning the lang files were loaded by the browser,
but never actually used.
The 'admin' module will be split off from 'framework',
where 'framework' only provides (mostly) frontend-agnostic PHP classes.
For example, HTMLEditorField.php has a TinyMCEConfig.php driver,
but doesn't come with its own JS includes.
Multiple entry points can't result in a single bundle.css with a fixed filename, see
https://github.com/webpack/extract-text-webpack-plugin/issues/179
Until that's resolved, it's easier to keep the 'css' task separate in Webpack,
and have a single entry point for all CSS (bundle.scss).
Also partially reverting "Moved frontend assets into admin/ "module"",
which moved too many files: debug.css and install.css need to remain
as framework (not admin) deps. Split out into a separate `framework-css` Webpack
task in preparation for splitting off the module.
The JavaScript i18n functionality in SilverStripe is used in the CMS as well as form field implementations.
Form fields used to include their own JavaScript for usage outside of CMS. This now requires custom build tooling in a project.
Hence there's no need for an i18n shim (i18nx.js), since the CMS always uses i18n support.
We've removed the ability to directly reference JS and CSS files
for form fields and other SilverStripe features in favour of a common bundle built by Webpack.
The logical next step is to make the framework module free of frontend dependencies,
which should simplify its operation, and avoid another time intensive "npm install" on a module.
Used in iframe, so can't be rolled into other code.
Moved in admin/ since that's easier for now with Webpack entry points,
and we'll move all JS/CSS into admin/ anyway soon.
There's not a lot of benefit in packaging these separately in terms of initial CMS load size,
so let's simplify the setup. They'll eventually become lazy loaded chunks in a React-based setup
When adding the deps straight into the file (recommended),
the onchange handler in file-upload isn't firing properly when a file is uploaded through
the <input type=file> button - it falls back to default behaviour, which submits the
containing form, failing because the upload is handled by a different URL.
These were originally copied from node_modules via an "npm run thirdparty" task,
in order to have them loadable with oldschool <script> tags.
Since webpack supports CommonJS-style loading, that's no longer required,
we can simply inline those scripts into the bundle.
We need to use imports-loader though, in order to ensure
that "define" is not available in some module scopes,
which triggers AMD behavior that's not compatible with Webpack's loaders.
See http://webpack.github.io/docs/shimming-modules.html
I've had to pin to the exact versions used in the 3.x CMS,
since jquery-upload has introduced an AMD wrapper sometime
between 6.0 and 6.9 (the latest version NPM automatically pulls in).
This AMD wrapper confuses Webpack, since it's trying to resolve the
dependencies contained in it. We could create shims for those instead,
but the easiest way was to simply revert to the versions already used
before the Webpack migration (since the newer versions in node_modules
were never actually copied into thirdparty, they weren't used before).
