Search and Top Navigation
#10119 closed feature (fixed)
Opened June 19, 2014 05:34PM UTC
Closed July 21, 2015 03:00PM UTC
Last modified July 21, 2015 03:14PM UTC
All: Use AMD loader in demos and tests
| Reported by: | jzaefferer | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 1.12.0 |
| Component: | [meta] ui.dev | Version: | 1.11.1 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
For discussion: If we were to use an AMD loader in our demos and tests, replacing the individual script elements (demos) our custom script loader (tests), we could also simplify the UMD wrappers in our source files: Instead of using the relatively complicated UMD wrappers, we'd use plain define calls to specify dependencies and the factory function, then extend that at build time to include the full UMD wrapper. The unique parts are the dependencies and accordingly the parameters of the factory function, so it should be reasonable to generate the rest.
This would simplify the source files, reduce maintenance of demos, replace our custom script loader in tests and make it more reasonable to split modules into smaller chunks that can be shared across widgets. Currently we have core collecting various shared functions, which could then be split into individual files that are defined as dependencies as needed.
Attachments (0)
Change History (58)
Changed June 20, 2014 01:26AM UTC by comment:1
Changed June 20, 2014 09:03AM UTC by comment:2
As I remember, Scott wants source files to be consumable in UI (no build step in between).
That's why I'm suggesting this together with a change in how we files in demos and tests.
The structure in Globalize is still something I want the UI team to review together. Single function modules also have their drawbacks that we should discuss, like the long list of dependencies (and parameters) in some modules.
Changed June 24, 2014 12:29PM UTC by comment:3
I refuse to partake in any further discussion about module loaders and package managers, so I'm a +0 on this and all future discussions.
Changed August 20, 2014 04:46PM UTC by comment:4
| milestone: | none → 1.11.2 |
|---|---|
| priority: | minor → blocker |
| status: | new → open |
| version: | git → 1.11.1 |
We'll change demos and tests to use AMD via require.js, but leave the UMD wrappers in the source files. This will require updating the demo copying task in jqueryui.com as well.
Changed August 20, 2014 04:47PM UTC by comment:5
| milestone: | 1.11.2 → 1.12.0 |
|---|
Changed August 21, 2014 12:19AM UTC by comment:6
| summary: | All: Use AMD loader in demos and tests and simplify UMD → All: Use AMD loader in demos and tests |
|---|
Changed September 02, 2014 01:34PM UTC by comment:7
Rafael was updating spinner demos to use require.js as part of updating to Globalize 1.x. I've asked him to do the require.js update separately and create a PR for just one of the demos, then work on updating one of the unit tests. We can then use that to figure out and improve the details before updating everything else.
Changed November 12, 2014 05:09PM UTC by comment:8
Changed January 22, 2015 09:43PM UTC by comment:9
| priority: | blocker → major |
|---|
Same here, not a 1.12 blocker.
Changed April 09, 2015 01:31PM UTC by comment:10
Tests: Change test infrastructure to use AMD and reduce boilerplate
Ref #10119
Ref gh-1528
- Adds RequireJS and relies on AMD for loading dependencies.
- Updates to grunt-contrib-qunit 0.6.0.
- Convert
domEqual()to a proper QUnit assertion. - Introduces two bootstrap files (JS and CSS) which use
data-attributes to
reduce the amount of boilerplate needed in each test
Changeset: 7c896ddb8563e1f4fc655904614cf72d010e2ecb
Changed April 09, 2015 01:31PM UTC by comment:11
Tests: Convert closeEnough() to a proper QUnit assertion
Should eventually replace with qunit-assert-close.
Ref #10119
Ref gh-1528
Changeset: 2e1c72fb59b3e41da15ebcd83640dbdf13a90d27
Changed April 09, 2015 01:32PM UTC by comment:12
Accordion: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: e39ee9d6695cebd4ec138b1d5391c67c58d939a9
Changed April 09, 2015 01:32PM UTC by comment:13
Autocomplete: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: aff3c32ee1f0b81ecea613057e95a40d8edc6b03
Changed April 09, 2015 01:32PM UTC by comment:14
Button: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: f908a7793bf9e06f3e23d15028baf2e90e92baaa
Changed April 09, 2015 01:32PM UTC by comment:15
Core: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 9fb04e42a24263a88dc3adf1b9ce6a199309b24c
Changed April 09, 2015 01:32PM UTC by comment:16
Draggable: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: fbc55446fbc397f7f176fd907fd5da5ff3d3abad
Changed April 09, 2015 01:32PM UTC by comment:17
Effects: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: a0e3da0459e4fbbde99dfa5f41929fdc82dfde1e
Changed April 09, 2015 01:32PM UTC by comment:18
Menu: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: f2ca8f92f0d9ab9c7bf2e202e7ff7778daeef85c
Changed April 09, 2015 01:32PM UTC by comment:19
Position: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 739f9b3f6382195b6976abeb71fc4b09f75cc4e5
Changed April 09, 2015 01:32PM UTC by comment:20
Progressbar: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: df3e8c4deb07105eb8a387caf27d7a1f9ecdb02c
Changed April 09, 2015 01:32PM UTC by comment:21
Resizable: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 4e7407cd699bcb02cfdd6e28d463831e782233e7
Changed April 09, 2015 01:33PM UTC by comment:22
Selectable: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: b8625346f6de6d7533493fc27b24d8acd45aa84c
Changed April 09, 2015 01:33PM UTC by comment:23
Selectmenu: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 3522fd9618d196beb235f3bd52f85c31f20c57b8
Changed April 09, 2015 01:33PM UTC by comment:24
Slider: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: a856dd9b7e00982cbe4dc9a2dce8ca940728126d
Changed April 09, 2015 01:33PM UTC by comment:25
Sortable: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 31e36e6ae4e1552b9a79595695c13dce4f416d0b
Changed April 09, 2015 01:33PM UTC by comment:26
Tabs: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 94f5c15df97ca975f039788f6220650492d924be
Changed April 09, 2015 01:33PM UTC by comment:27
Widget: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 23a7a113ac61bb12ad6a3775553d5ac1426f82f6
Changed April 09, 2015 01:33PM UTC by comment:28
Spinner: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 8bda52c8d1d681f3afe5827f8eda10475377442f
Changed April 09, 2015 01:33PM UTC by comment:29
Datepicker: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 7d168ce6300a4b59f54c7b7f55c622a7a60ba222
Changed April 09, 2015 01:33PM UTC by comment:30
Tests: Support $.uiBackCompat = false via data-no-back-compat
Ref #10119
Ref gh-1528
Changeset: 0714f55ad48c9d3dace29003677353f5e152a13a
Changed April 09, 2015 01:33PM UTC by comment:31
Dialog: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 7d4811206f8b64e9bd8eea168a77edf23629659b
Changed April 09, 2015 01:33PM UTC by comment:32
Tooltip: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: a2da340e0d1b02d243c71b86382e5e624e7211d6
Changed April 09, 2015 01:33PM UTC by comment:33
Droppable: Convert tests to new infrastructure
Ref #10119
Ref gh-1528
Changeset: 669e62d61b52a31efc7666bf95d0bfe2df2f839d
Changed April 09, 2015 01:34PM UTC by comment:34
Tests: Remove old test infrastructure
Ref #10119
Ref gh-1528
Changeset: 42566bdd037ac57cf7d6d7a5d059db2ba42518d9
Changed April 09, 2015 01:34PM UTC by comment:35
Tests: Widget test helpers extend the main helper
Ref #10119
Ref gh-1528
Changeset: dc4b015a8b9acdb5bff2d5dd89737b3d8b64097f
Changed April 09, 2015 01:34PM UTC by comment:36
Build: Upgrade to qunit-composite 1.1.0
Ref #10119
Closes gh-1528
Changeset: f499569bffae60a6a7161eb2e13ec409afb98450
Changed July 21, 2015 03:00PM UTC by comment:37
| resolution: | → fixed |
|---|---|
| status: | open → closed |
Demos: Add new infrastructure using a require.js bootstrap
Fixes #10119
Closes gh-1557
Changeset: 7336a5869ceb2bf27779b5f089277c365fc7d278
Changed July 21, 2015 03:01PM UTC by comment:38
Accordion: Use new demos infrastructure
Ref #10119
Changeset: 9ef415042598ad978414f832b7bf52f20c67cce1
Changed July 21, 2015 03:01PM UTC by comment:39
Datepicker: Use new demos infrastructure
Ref #10119
Changeset: 4c223432816409369e364893b3e890596d639c9c
Changed July 21, 2015 03:02PM UTC by comment:40
Datepicker: Update localization demo to use i18n files from ui folder
Ref #10119
Changeset: 9484718a00d68a36f5600c6c49365d134d1df79e
As I remember, Scott wants source files to be consumable in UI (no build step in between). If we were ok with a build step, in the other hand, your solution makes sense. It's what Globalize does.
I'm copy&pasting a 2013/12/24 email I sent to the group about a kinda similar discussion.
The distinction between source vs. distributable files is much more salient when we talk about C (or other compiled languages), than when we talk about javascript (or other interpreted languages). Although, for larger projects, the distinction may arise. Because, they serve different purposes... In my vision, we have this:
Sources files: should be organized for easy development.
Distributable files: should be organized for easy use.
Recently, I have been given the opportunity to refactor our Globalize project to use CLDR as database foundation. Anyway... I see Globalize in the middle of Core and UI/Mobile in a modularity aspect. I'd like to talk a little about its organization, which I cloned from Core, but instead of building one single distribution file, it builds n distribution-module files (similar to UI/Mobile, but perhaps not as granular as UI/Mobile).
Making source files as granular as possible help unit testing them. If every function is exposed as a single file, unit tests will access (and therefore test) every single function. This is not possible when such functions are not exposed eg. in bigger compositions (where some functions may serve as private functions). <- When we test that, we do functional (not unit) tests.
Globalize's distribution files are built into:
dist/globalize.js
dist/globalize/date.js
dist/globalize/number.js
dist/globalize/...
Those files are UMD wrapped. All source excessive/overhead wrappers are cut off (like Core, or modernizr does). Then, those distributables files are functional tested. Those files are the ones user should use. We (developers) have the freedom to compose them the way we want.
I am not stating this should be a solution for UI / Mobile. Because, different projects have different needs and purposes. But, maybe it can be used as another reference for evaluation.
For reference the above email was sent as an reply for Gabriel and Scott. The original subject was: "Repo files vs. downloadable".