#10119 closed feature (fixed)
All: Use AMD loader in demos and tests
| Reported by: | Jörn Zaefferer | 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.
Change History (58)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
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.
comment:3 Changed 9 years ago by
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.
comment:4 Changed 9 years ago by
| 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.
comment:5 Changed 9 years ago by
| Milestone: | 1.11.2 → 1.12.0 |
|---|
comment:6 Changed 9 years ago by
| Summary: | All: Use AMD loader in demos and tests and simplify UMD → All: Use AMD loader in demos and tests |
|---|
comment:7 Changed 9 years ago by
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.
comment:10 Changed 8 years ago by
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
comment:11 Changed 8 years ago by
Tests: Convert closeEnough() to a proper QUnit assertion
Should eventually replace with qunit-assert-close.
Ref #10119 Ref gh-1528
Changeset: 2e1c72fb59b3e41da15ebcd83640dbdf13a90d27
comment:12 Changed 8 years ago by
Accordion: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: e39ee9d6695cebd4ec138b1d5391c67c58d939a9
comment:13 Changed 8 years ago by
Autocomplete: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: aff3c32ee1f0b81ecea613057e95a40d8edc6b03
comment:14 Changed 8 years ago by
Button: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: f908a7793bf9e06f3e23d15028baf2e90e92baaa
comment:15 Changed 8 years ago by
Core: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 9fb04e42a24263a88dc3adf1b9ce6a199309b24c
comment:16 Changed 8 years ago by
Draggable: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: fbc55446fbc397f7f176fd907fd5da5ff3d3abad
comment:17 Changed 8 years ago by
Effects: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: a0e3da0459e4fbbde99dfa5f41929fdc82dfde1e
comment:18 Changed 8 years ago by
Menu: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: f2ca8f92f0d9ab9c7bf2e202e7ff7778daeef85c
comment:19 Changed 8 years ago by
Position: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 739f9b3f6382195b6976abeb71fc4b09f75cc4e5
comment:20 Changed 8 years ago by
Progressbar: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: df3e8c4deb07105eb8a387caf27d7a1f9ecdb02c
comment:21 Changed 8 years ago by
Resizable: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 4e7407cd699bcb02cfdd6e28d463831e782233e7
comment:22 Changed 8 years ago by
Selectable: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: b8625346f6de6d7533493fc27b24d8acd45aa84c
comment:23 Changed 8 years ago by
Selectmenu: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 3522fd9618d196beb235f3bd52f85c31f20c57b8
comment:24 Changed 8 years ago by
Slider: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: a856dd9b7e00982cbe4dc9a2dce8ca940728126d
comment:25 Changed 8 years ago by
Sortable: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 31e36e6ae4e1552b9a79595695c13dce4f416d0b
comment:26 Changed 8 years ago by
Tabs: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 94f5c15df97ca975f039788f6220650492d924be
comment:27 Changed 8 years ago by
Widget: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 23a7a113ac61bb12ad6a3775553d5ac1426f82f6
comment:28 Changed 8 years ago by
Spinner: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 8bda52c8d1d681f3afe5827f8eda10475377442f
comment:29 Changed 8 years ago by
Datepicker: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 7d168ce6300a4b59f54c7b7f55c622a7a60ba222
comment:30 Changed 8 years ago by
Tests: Support $.uiBackCompat = false via data-no-back-compat
Ref #10119 Ref gh-1528
Changeset: 0714f55ad48c9d3dace29003677353f5e152a13a
comment:31 Changed 8 years ago by
Dialog: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 7d4811206f8b64e9bd8eea168a77edf23629659b
comment:32 Changed 8 years ago by
Tooltip: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: a2da340e0d1b02d243c71b86382e5e624e7211d6
comment:33 Changed 8 years ago by
Droppable: Convert tests to new infrastructure
Ref #10119 Ref gh-1528
Changeset: 669e62d61b52a31efc7666bf95d0bfe2df2f839d
comment:34 Changed 8 years ago by
Tests: Remove old test infrastructure
Ref #10119 Ref gh-1528
Changeset: 42566bdd037ac57cf7d6d7a5d059db2ba42518d9
comment:35 Changed 8 years ago by
Tests: Widget test helpers extend the main helper
Ref #10119 Ref gh-1528
Changeset: dc4b015a8b9acdb5bff2d5dd89737b3d8b64097f
comment:36 Changed 8 years ago by
Build: Upgrade to qunit-composite 1.1.0
Ref #10119 Closes gh-1528
Changeset: f499569bffae60a6a7161eb2e13ec409afb98450
comment:37 Changed 8 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
Demos: Add new infrastructure using a require.js bootstrap
Fixes #10119 Closes gh-1557
Changeset: 7336a5869ceb2bf27779b5f089277c365fc7d278
comment:38 Changed 8 years ago by
Accordion: Use new demos infrastructure
Ref #10119
Changeset: 9ef415042598ad978414f832b7bf52f20c67cce1
comment:39 Changed 8 years ago by
Datepicker: Use new demos infrastructure
Ref #10119
Changeset: 4c223432816409369e364893b3e890596d639c9c
comment:40 Changed 8 years ago by
Datepicker: Update localization demo to use i18n files from ui folder
Ref #10119
Changeset: 9484718a00d68a36f5600c6c49365d134d1df79e
comment:41 Changed 8 years ago by
Autocomplete: Update demos to use AMD
Ref #10119
Changeset: 0935c9af366bfc412db4cc2bea8b544d5588a7b2
comment:42 Changed 8 years ago by
comment:43 Changed 8 years ago by
Draggable: Update to demos to use AMD
Ref #10119
Changeset: 41b5b2d7a9def3298a205150d0a8428c86798dcd
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".