iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/packages/router
History
Paul Gschwendtner 6d3a25d897 ci: run acceptance tests on saucelabs with ivy (#34277) 
Currently we only run Saucelabs on PRs using the legacy View Engine
build. Switching that build to Ivy is not trivial and there are various
options:

  1. Updating the R3 switches to use POST_R3 by default. At first glance,
  this doesn't look easy because the current ngtsc switch logic seems to
  be unidirectional (only PRE_R3 to POST_R3).

  2. Updating the legacy setup to run with Ivy. This sounds like the easiest
  solution at first.. but it turns out to be way more complicated. Packages
  would need to be built with ngtsc using legacy tools (i.e. first building
  the compiler-cli; and then building packages) and View Engine only tests
  would need to be determined and filtered out. Basically it will result in
  re-auditing all test targets. This is contradictory to the fact that we have
  this information in Bazel already.

  3. Creating a new job that runs tests on Saucelabs with Bazel. We specify
  fine-grained test targets that should run. This would be a good start
  (e.g. acceptance tests) and also would mean that we do not continue maintaining
  the legacy setup..

This commit implements the third option as it allows us to move forward
with the general Bazel migration. We don't want to spend too much time
on our legacy setup since it will be removed anyway in the future.

PR Close #34277
 		2019-12-16 07:43:41 -08:00
..
scripts refactor: move angular source to /packages rather than modules/@angular 2017-03-08 16:29:27 -08:00
src Revert "refactor: use isObservable provided by rxjs 6.1+ (#27668)" 2019-11-27 13:00:59 -08:00
test ci: run acceptance tests on saucelabs with ivy (#34277) 2019-12-16 07:43:41 -08:00
testing refactor(core): Migrate TestBed.get to TestBed.inject (#32382) 2019-09-09 19:10:54 -04:00
upgrade build: ts_web_test & ts_web_test_suite deprecated in favor of karma_web_test & karma_web_test_suite (#33802) 2019-11-13 13:33:38 -08:00
.gitignore refactor: move angular source to /packages rather than modules/@angular 2017-03-08 16:29:27 -08:00
BUILD.bazel build: convert entry_point to label (#30627) 2019-06-11 00:03:11 +00:00
PACKAGE.md docs: add package doc files (#26047) 2018-10-05 15:42:14 -07:00
README.md docs(router): remove obsolete sections in README.md (#27880) 2019-01-11 11:15:59 -08:00
index.ts refactor: move angular source to /packages rather than modules/@angular 2017-03-08 16:29:27 -08:00
karma-test-shim.js test(ivy): run router tests with ivy on CI (#27195) 2018-11-21 09:19:40 -08:00
karma.conf.js build: reference zone.js from source directly instead of npm. (#33046) 2019-11-06 00:48:34 +00:00
package.json build: set up all packages to publish via wombot proxy (#33747) 2019-11-13 11:34:33 -08:00
public_api.ts build: publish tree of files rather than FESMs (#18541) 2017-08-31 15:34:50 -07:00

README.md

Angular Router

Managing state transitions is one of the hardest parts of building applications. This is especially true on the web, where you also need to ensure that the state is reflected in the URL. In addition, we often want to split applications into multiple bundles and load them on demand. Doing this transparently isn’t trivial.

The Angular router is designed to solve these problems. Using the router, you can declaratively specify application state, manage state transitions while taking care of the URL, and load components on demand.

Guide

Read the dev guide here.