GithubHelp home page GithubHelp logo

projects's Introduction

Projects Build Status

A Github client built with Angular 2

https://projects.angularjs.org

Continuous Deployment

Whenever a change is pushed to master, Travis runs the e2e tests and pushes the result of the build to the dist branch.

The server behind projects.angularjs.org listens for changes to the dist branch (via a Webhook) and pulls them in to serve them. It uses the continuous-deployment.js node script to do that.

Setup

  1. Install NodeJS
  2. npm install -g gulp
  3. npm install -g bower
  4. npm install -g protractor
  5. npm install
  6. bower install

Running the Samples

  1. gulp build watch serve
  2. open http://localhost:8000/

Running e2e tests locally

  1. Start the server: gulp build watch serve
  2. Start the selenium server: webdriver-manager start
  3. protractor protractor.conf.js

Multi project development

  • call scripts/dev-dep.sh to replace a dependency in node_modules with a symlink. E.g. scripts/dev-dep.sh templating will replace node_modules/templating with a symlink to ../templating. If that folder already exists it will just use it. Otherwise it will clone templating from Github and store it there.
  • call scripts/npm-dep.sh to revert this change.
  • when dependencies changed, increment the counter in FORCE_BUILD to force a build

Code Style Guide

  • Use 2 spaces as tab, see .editorconfig

projects's People

Contributors

eisenbergeffect avatar jeffbcross avatar petebacondarwin avatar tbosch avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

projects's Issues

Set up nginx directive to support pushState

The configuration is in the private "angular-sites" repo in the "dotprojects" directory. There should be a general rule to rewrite pushState-friendly URLs to index.html.

There are a couple of ways to handle this:

  • Write separate rules for each view path (e.g. rewrite /issues/* & /projects/* to index.html)
  • Write rule to rewrite all requests except for directories of known assets (/img /css, etc). This does not support our recommended best practice directory structure

lib/platform.js is missing

I run

gulp build serve

and then access localhost:8000 and the app fails with a 404 on lib/platform.js.

Should I retrieve this from somewhere?

Fails when following Readme Setup instructions

Setup

  1. Install NodeJS
  2. npm install -g gulp
  3. npm install -g bower
  4. npm install -g protractor
  5. npm install
  6. bower install

Running the Samples

  1. gulp build watch serve
  2. open http://localhost:8000/
Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8000/lib/router/index.js
Error: Script error for: libPath/router/index
http://requirejs.org/docs/errors.html#scripterror
    at makeError (http://localhost:8000/lib/require.js:166:17)
    at HTMLScriptElement.context.onScriptError (http://localhost:8000/lib/require.js:1689:36)
    at Zone.run (http://localhost:8000/lib/zone.js:87:19)
    at HTMLScriptElement.zoneBoundFn (http://localhost:8000/lib/zone.js:64:19) bootstrap.js:54
GET http://localhost:8000/lib/platform.js.map 404 (Not Found) 

When I look in the dist folder I notice the following:

lib/router only has a router-directive.js file, not an index.js file, so no wonder I get a 404.
The file lib/platform.js.map is also not present, only the lib/platform.js.

Please fix the setup guide. Thanks :)

Extreemly Fast Dirty Checking

Intents - Dirty Checking Optimization

This solution should allow to optimize (or even skip) dirty checking by analyzing effects in the GlobalState of the IntentExecution . In other words - the application would be able to analyze itself - and deduce changes Intent makes to the GlobalState. In the ideal implementation, we would need no dirty checking at all, and the Intent should perform as fast as vanilla js implementation.

Glossary

  • Intent - program / some piece of runnable code
  • IntentExecution - Representation of Intent execution which may change the GlobalState.
  • GlobalState - the current state of the Application

An example of Intent:

  • UserEventHandler (MouseEvent, DeviceOrientationEvent etc.)
  • BrowserEventHandler (XMLHttpRequest, window.on, etc.)
  • RuntimeEventHandler (setInterval, requestAnimationFrame, etc.)
  • Other (?)

In case of Angluar 2.0 Components, we would be interested only in

Intents dealing (also indirectly) with the Components - Intents that would change the GlobalState (in terms of Angular 1.0: everything what is being $watched).

Deductive Implementation:

Knowing what is going to change requires analyzing the
IntentExecution. Basically this means analyzing the part of the
source code that is about to run the context of current state, and
deducing what the IntentExecution may be changing in the Global
State. Analyzing the data flow should be sufficient and fast. We would be able to mark what may be changed by the IntentExecution and perform dirty checking only on those objects.

Runtime Implementation:

Provided Angular could include a simplistic version of the Runtime and Application - performing only data flow and marking only changes made in the Global State. This implementation could yield higher performance as it should allow to be highly optimized by the JIT since it only would represent a data flow.

In case of very complex Intents or "ambiguous" Intents Angular could back-off to dirty checking implementation.

Implementation is based on CFG analysis. IntentExecutionAnalyzer would parse the AST of
the Intent and perform a data flow analysis AST 2 CFG (IntentExecution) looking for parts that could mutate the Global State.
It could do something similar to escope, cfg.js

This solution might be used in build time (there would be little chance of optimizing dynamic code) or build into angular (runtime).

At this point this is only a foggy idea, more details could be provided after trying to build first prototype.

I have to little idea about AST, CFG, DFA, NFA etc. to provide more help at this point.

Use or change best practices

From skipping over the source it seems that this project doesn't use the best practice guide introduced by Angular earlier this year (https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub). It's quite sad that from my experience really few people follow this guide and that none (?) of Angulars own projects encourages the guide - so it became quite pointless. I understand that https://github.com/angular/angular-phonecat and https://github.com/angular/angular-seed are maybe to small for the recommended practices in the guide and that they were created earlier. However this is a new project and it seems to have a larger scale which is really good. If there was ever a public big project from the Angular team itself it seems that it is this one. So please use or change the best practice guide.

FYI:
I tried to follow this guide in enterprise projects and hit some walls. I currently use it with some modifications. Example app structure:

karma.conf.js
protractor.conf.js
dgeni.conf.js
dist/
src/
  index.html
  style.css
  app.js
  app_e2e.js
  user/
    user.html
    user.css
    user.js
    user_e2e.js
    user-controller.js
    user-controller_test.js
    user-filter.js
    user-filter_test.js

Every JS file without a controller/filter/service/directive/etc.-suffix is just a module containing value, constant, config and/or run functions (e.g. app.js, user.js).
Every JS file with a controller/filter/service/directive/etc.-Suffix contains the type of functionality described in the suffix, but is a module, too. E.g. user-controller.js has a module name like app.user.controller. user.js has a module name like app.user and declares app.user.controller as a dependency. As every file is a module itself and Angular handles the dependency tree the build configuration becomes really simple: it's just a concat with two globs [ 'src/**/*.js', '!src/**/*_{test,e2e}.js' ].

Every JS file without a controller/filter/service/directive/etc.-suffix can have a _e2e-suffix which refers to a proctector file for end-2-end tests.
Every JS file with a controller/filter/service/directive/etc.-suffix can have a _test-suffix which refers to a karma file for unit tests.
With my experience these separation for tests scales very well and feels very natural. Most of the stuff happening in modules is only suited for e2e-tests while controllers, services, etc. can be test quite well with unit-tests. If a module contains very custom logic in a run and config function which can't be extracted into a service I sometimes also add unit tests for these case (e.g. a user_test.js).

Like the example with concat this structure helps a lot in the build configuration. I test our coding style with jscs for all js files with a simple 'src/**/*.js' as it doesn't matter if I write a test or a source file. jshint however is targeted for [ 'src/**/*.js', '!src/**/*_{test,e2e}.js' ] and 'src/**/*_{test,e2e}.js' separately to target different rules, globals, etc. for Node and browser environment.

Configuration files for Karma, Protractor and Dgeni are all named in a similar fashion: (type).conf.js. (I generally try to name JS files as configurations consistently as (type).conf.js and JSON files as configurations as .(type)rc like .jscsrc or .jshintrc. Some frameworks force this, some not...) If I need to be more specific I again use suffixes like protractor-travis.conf.js and protractor-jenkins.conf.js.

(Note: The _test suffix could also be named _unit which would be more consistent to _e2e, but if someone already used the best practice guide before this person would be more familiar with _test so I didn't rename it.)

Anyway... I don't want to spam you and don't want to say that my way would be the right way. I just want to provide some feedback which could be beneficial for others.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.