├── src ├── common │ └── stores │ │ └── selected-event.jsx ├── app.jsx ├── index.jsx ├── selected-event │ └── components │ │ └── selected-event.jsx ├── actions.js └── results │ └── components │ └── eventbrite.jsx ├── .gitignore ├── dist └── index.html ├── test ├── test_helper.js └── eventbrite_spec.jsx ├── webpack.config.js ├── README.md ├── package.json ├── CONTRIBUTING.md └── STYLE-GUIDE.md /src/common/stores/selected-event.jsx: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | #dependencies 2 | node_modules -------------------------------------------------------------------------------- /dist/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 |

5 | 6 | 7 | -------------------------------------------------------------------------------- /test/test_helper.js: -------------------------------------------------------------------------------- 1 | import jsdom from 'jsdom'; 2 | import chai from 'chai'; 3 | import chaiImmutable from 'chai-immutable'; 4 | 5 | 6 | const doc = jsdom.jsdom(''); 7 | const win = doc.defaultView; 8 | 9 | global.document = doc; 10 | global.window = win; 11 | 12 | Object.keys(window).forEach((key) => { 13 | if(!(key in global)) { 14 | global[key] = window[key]; 15 | } 16 | }); 17 | 18 | chai.use(chaiImmutable); -------------------------------------------------------------------------------- /src/app.jsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import {List} from 'immutable'; 3 | import EBData from 'json!./results/stores/eventbrite.json'; 4 | 5 | 6 | 7 | const fixedEvents = EBData.events.map(function(event){ 8 | event.logo ? event.logo.url : event.logo = {url: 'http://goo.gl/W9RF2D'} 9 | return event; 10 | }); 11 | 12 | const events = List.of(...fixedEvents); 13 | 14 | export default React.createClass({ 15 | render: function() { 16 | return React.cloneElement(this.props.children, {events: events}); 17 | } 18 | }); -------------------------------------------------------------------------------- /src/index.jsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import ReactDOM from 'react-dom'; 3 | import Router, {Route} from 'react-router'; 4 | import App from './app'; 5 | import Eventbrite from './results/components/eventbrite'; 6 | import Selected from './selected-event/components/selected-event'; 7 | import Data from 'json!./results/stores/eventbrite.json'; 8 | 9 | const routes = 10 | 11 | 12 | 13 | ; 14 | 15 | ReactDOM.render( 16 | {routes}, 17 | document.getElementById('app') 18 | ); -------------------------------------------------------------------------------- /src/selected-event/components/selected-event.jsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import EBData from 'json!./../../results/stores/eventbrite.json'; 3 | 4 | console.log('Selected event test: ', EBData.events[1].name); 5 | var selected = EBData.events[1]; 6 | 7 | export default React.createClass({ 8 | render: function() { 9 | return

10 |

11 |

12 |

{selected.name.text}

13 |

{selected.description.text}

14 |

15 |

16 | } 17 | 18 | }); -------------------------------------------------------------------------------- /src/actions.js: -------------------------------------------------------------------------------- 1 | export const SEARCH = 'SEARCH'; 2 | export const GET_API_RESULTS = 'GET_API_RESULTS'; 3 | // export const RENDER_API_RESULTS = 'RENDER_API_RESULTS'; 4 | export const SELECT_EVENT = 'SELECT_EVENT'; 5 | 6 | export const filters = { 7 | CITY: 'CITY', 8 | STARTDATE: 'STARTDATE', 9 | ENDDATE: 'ENDDATE', 10 | GENRE: 'GENRE', 11 | ARTIST: 'ARTIST', 12 | VENUE: 'VENUE' 13 | } 14 | 15 | export function search(searchObj = {}) { 16 | return { type: SEARCH, searchObj}; 17 | } 18 | 19 | export function getAPIResults(apiResults) { 20 | return {type: GET_API_RESULTS, apiResults}; 21 | } 22 | 23 | export function selectEvent(event) { 24 | return {type: SELECT_EVENT, event}; 25 | } 26 | -------------------------------------------------------------------------------- /webpack.config.js: -------------------------------------------------------------------------------- 1 | var webpack = require('webpack'); 2 | 3 | module.exports = { 4 | entry: [ 5 | 'webpack-dev-server/client?http://localhost:8080', 6 | 'webpack/hot/only-dev-server', 7 | './src/index.jsx' 8 | ], 9 | module: { 10 | loaders: [{ 11 | test: /\.jsx?$/, 12 | exclude: /node_modules/, 13 | loader: 'react-hot!babel' 14 | }] 15 | }, 16 | resolve: { 17 | extensions: ['', '.js', '.jsx'] 18 | }, 19 | output: { 20 | path: __dirname + '/dist', 21 | publicPath: '/', 22 | filename: 'bundle.js' 23 | }, 24 | devServer: { 25 | contentBase: './dist', 26 | hot: true 27 | }, 28 | plugins: [ 29 | new webpack.HotModuleReplacementPlugin() 30 | ] 31 | 32 | } -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | #Soundglom React 2 | This project is a refactor of a previous version from Angular to React/Redux. With consideration to the multiple user stories and their implementations, we've found that with React, application scaling to meet the demands of the user story is much easier. React is also giving us more control over how we want to implement, connect and keep components autonomous. If you'd like to contribute, send a message and we'll provide you with the User Story. 3 | 4 | See the original [Soundglomerate repo](https://github.com/De-La-Soul/soundglomerate) for more information. 5 | 6 | ##Getting Started 7 | 8 | **first** 9 | - `$ npm install` 10 | - `$ npm npm install -g webpack` 11 | - `$ npm npm install -g webpack-dev-server` 12 | 13 | **then** 14 | - `$ webpack` 15 | - `$ webpack-dev-server` 16 | 17 | **Navigate to localhost:8080** 18 | 19 | ##Contributing 20 | *Send us a message or create an issue if you'd like a copy of the user story.* 21 | - [Contribution guide](CONTRIBUTING.md) 22 | - [Style guide](STYLE-GUIDE.md) 23 | -------------------------------------------------------------------------------- /src/results/components/eventbrite.jsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import PureRenderMixin from 'react-addons-pure-render-mixin'; 3 | 4 | export default React.createClass({ 5 | mixins: [PureRenderMixin], 6 | getInitialState: function() { 7 | return { 8 | eventBriteEvent: null 9 | } 10 | }, 11 | handleClick: function(event) { 12 | console.log("This event", event); 13 | // this.setState({eventBriteEvent: this.state.event}); 14 | }, 15 | getEvent: function() { 16 | // console.log('this.props', this.props); 17 | return this.props.events || []; 18 | }, 19 | render: function() { 20 | return (

21 | {this.getEvent().map(event => 22 |

23 |

24 |

25 |

{event.name.text}

26 |

{event.description.text}

27 |

28 |

29 | )} 30 |

); 31 | } 32 | }); -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "sg-react", 3 | "version": "1.0.0", 4 | "description": "", 5 | "main": "index.js", 6 | "scripts": { 7 | "test": "mocha --compilers js:babel-core/register --require ./test/test_helper.js 'test/**/*.@(js|jsx)'", 8 | "test:watch": "npm run test -- --watch" 9 | }, 10 | "keywords": [], 11 | "author": "", 12 | "license": "ISC", 13 | "devDependencies": { 14 | "babel-core": "^6.3.17", 15 | "babel-loader": "^6.2.0", 16 | "babel-preset-es2015": "^6.3.13", 17 | "babel-preset-react": "^6.3.13", 18 | "chai": "^3.4.1", 19 | "chai-immutable": "^1.5.3", 20 | "jsdom": "^7.2.0", 21 | "json-loader": "^0.5.4", 22 | "mocha": "^2.3.4", 23 | "react-addons-pure-render-mixin": "^0.14.3", 24 | "react-dom": "^0.14.3", 25 | "react-hot-loader": "^1.3.0", 26 | "webpack": "^1.12.9", 27 | "webpack-dev-server": "^1.14.0" 28 | }, 29 | "babel": { 30 | "presets": [ 31 | "es2015", 32 | "react" 33 | ] 34 | }, 35 | "dependencies": { 36 | "history": "^1.13.1", 37 | "immutable": "^3.7.5", 38 | "react-addons-pure-render-mixin": "^0.14.3", 39 | "react-router": "^1.0.0-rc3" 40 | } 41 | } 42 | -------------------------------------------------------------------------------- /test/eventbrite_spec.jsx: -------------------------------------------------------------------------------- 1 | import React from 'react/addons'; 2 | import {List} from 'immutable'; 3 | import Eventbrite from './../src/results/components/eventbrite'; 4 | import {expect} from 'chai'; 5 | import Data from 'json!/../../src/results/stores/eventbrite.json'; 6 | 7 | 8 | const {renderIntoDocument, scryRenderedDOMComponentsWithTag, findRenderedDOMComponentWithClass, findRenderedDOMComponentWithTag, Simulate} = React.addons.TestUtils; 9 | 10 | 11 | describe('Eventbrite events', () => { 12 | 13 | it('renders the titles of 2 events', () =>{ 14 | const testEvents = List.of(Data.events[1], Data.events[2]); 15 | 16 | let selected; 17 | 18 | const selectEvent = (event) => selected => event; 19 | 20 | const component = renderIntoDocument( 21 | 25 | ); 26 | 27 | const divisions = scryRenderedDOMComponentsWithTag(component, 'div'); 28 | const eventImage = scryRenderedDOMComponentsWithTag(component, 'img'); 29 | // const divisions1 = findRenderedDOMComponentWithTag(component, 'div'); 30 | // const eventInfo = findRenderedDOMComponentWithClass(component, 'eventInfo'); 31 | 32 | Simulate.click(divisions[0].children); 33 | 34 | console.dir(testEvents); 35 | // console.log('Div elements: ', eventImage); 36 | // console.log('Eventinfo elements: ', eventInfo); 37 | 38 | 39 | // console.log("Logging titles", titles); 40 | // // console.log("Logging eventImage", eventImage); 41 | // // expect(eventImage.length).to.equal(2); 42 | expect(divisions.length).to.equal(2); 43 | // expect(titles.length).to.equal(5); 44 | // expect(divisions[0].children[0].tagName).to.equal('IMG'); 45 | // expect(titles[0].children[1].children[0].tagName).to.equal('H2'); 46 | // expect(titles[0].children[1].children[1].tagName).to.equal('P'); 47 | 48 | 49 | // expect(titles[0].children[0].).to.equal('IMG'); 50 | // expect(titles[1].children[1].tagName).to.equal('IMG'); 51 | }) 52 | }); -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | ## General Workflow 4 | 5 | 1. Fork the repo 6 | 1. Cut a namespaced feature branch from master 7 | - bug/... 8 | - feat/... 9 | - test/... 10 | - doc/... 11 | - refactor/... 12 | 1. Make commits to your feature branch. Prefix each commit like so: 13 | - (feat) Added a new feature 14 | - (fix) Fixed inconsistent tests [Fixes #0] 15 | - (refactor) ... 16 | - (cleanup) ... 17 | - (test) ... 18 | - (doc) ... 19 | 1. When you've finished with your fix or feature, Rebase upstream changes into your branch. submit a [pull request][] 20 | directly to master. Include a description of your changes. 21 | 1. Your pull request will be reviewed by another maintainer. The point of code 22 | reviews is to help keep the codebase clean and of high quality and, equally 23 | as important, to help you grow as a programmer. If your code reviewer 24 | requests you make a change you don't understand, ask them why. 25 | 1. Fix any issues raised by your code reviwer, and push your fixes as a single 26 | new commit. 27 | 1. Once the pull request has been reviewed, it will be merged by another member of the team. Do not merge your own commits. 28 | 29 | ## Detailed Workflow 30 | 31 | ### Fork the repo 32 | 33 | Use github’s interface to make a fork of the repo, then add that repo as an upstream remote: 34 | 35 | ``` 36 | git remote add upstream https://github.com/Shinobi881/SG-React-1.git 37 | ``` 38 | 39 | ### Cut a namespaced feature branch from master 40 | 41 | Your branch should follow this naming convention: 42 | - bug/... 43 | - feat/... 44 | - test/... 45 | - doc/... 46 | - refactor/... 47 | 48 | These commands will help you do this: 49 | 50 | ``` bash 51 | 52 | # Creates your branch and brings you there 53 | git checkout -b `your-branch-name` 54 | ``` 55 | 56 | ### Make commits to your feature branch. 57 | 58 | Prefix each commit like so 59 | - (feat) Added a new feature 60 | - (fix) Fixed inconsistent tests [Fixes #0] 61 | - (refactor) ... 62 | - (cleanup) ... 63 | - (test) ... 64 | - (doc) ... 65 | 66 | Make changes and commits on your branch, and make sure that you 67 | only make changes that are relevant to this branch. If you find 68 | yourself making unrelated changes, make a new branch for those 69 | changes. 70 | 71 | #### Commit Message Guidelines 72 | 73 | - Commit messages should be written in the present tense; e.g. "Fix continuous 74 | integration script". 75 | - The first line of your commit message should be a brief summary of what the 76 | commit changes. Aim for about 70 characters max. Remember: This is a summary, 77 | not a detailed description of everything that changed. 78 | - If you want to explain the commit in more depth, following the first line should 79 | be a blank line and then a more detailed description of the commit. This can be 80 | as detailed as you want, so dig into details here and keep the first line short. 81 | 82 | ### Rebase upstream changes into your branch 83 | 84 | Once you are done making changes, you can begin the process of getting 85 | your code merged into the main repo. Step 1 is to rebase upstream 86 | changes to the master branch into yours by running this command 87 | from your branch: 88 | 89 | ```bash 90 | git pull --rebase upstream master 91 | ``` 92 | 93 | This will start the rebase process. You must commit all of your changes 94 | before doing this. If there are no conflicts, this should just roll all 95 | of your changes back on top of the changes from upstream, leading to a 96 | nice, clean, linear commit history. 97 | 98 | If there are conflicting changes, git will start yelling at you part way 99 | through the rebasing process. Git will pause rebasing to allow you to sort 100 | out the conflicts. You do this the same way you solve merge conflicts, 101 | by checking all of the files git says have been changed in both histories 102 | and picking the versions you want. Be aware that these changes will show 103 | up in your pull request, so try and incorporate upstream changes as much 104 | as possible. 105 | 106 | You pick a file by `git add`ing it - you do not make commits during a 107 | rebase. 108 | 109 | Once you are done fixing conflicts for a specific commit, run: 110 | 111 | ```bash 112 | git rebase --continue 113 | ``` 114 | 115 | This will continue the rebasing process. Once you are done fixing all 116 | conflicts you should run the existing tests to make sure you didn’t break 117 | anything, then run your new tests (there are new tests, right?) and 118 | make sure they work also. 119 | 120 | If rebasing broke anything, fix it, then repeat the above process until 121 | you get here again and nothing is broken and all the tests pass. 122 | 123 | ### Make a pull request 124 | 125 | Make a clear pull request from your fork and branch to the upstream master 126 | branch, detailing exactly what changes you made and what feature this 127 | should add. The clearer your pull request is the faster you can get 128 | your changes incorporated into this repo. 129 | 130 | At least one other person MUST give your changes a code review, and once 131 | they are satisfied they will merge your changes into upstream. Alternatively, 132 | they may have some requested changes. You should make more commits to your 133 | branch to fix these, then follow this process again from rebasing onwards. 134 | 135 | Once you get back here, make a comment requesting further review and 136 | someone will look at your code again. If they like it, it will get merged, 137 | else, just repeat again. 138 | 139 | Thanks for contributing! 140 | 141 | ### Guidelines 142 | 143 | 1. Uphold the current code standard: 144 | - Keep your code [DRY][]. 145 | - Apply the [boy scout rule][]. 146 | - Follow [STYLE-GUIDE.md](STYLE-GUIDE.md) 147 | 1. Run the [tests][] before submitting a pull request. 148 | 1. Tests are very, very important. Submit tests if your pull request contains 149 | new, testable behavior. 150 | 1. Your pull request is comprised of a single ([squashed][]) commit. 151 | 152 | ## Checklist: 153 | 154 | This is just to help you organize your process 155 | 156 | - [ ] Did I cut my work branch off of master (don't cut new branches from existing feature brances)? 157 | - [ ] Did I follow the correct naming convention for my branch? 158 | - [ ] Is my branch focused on a single main change? 159 | - [ ] Do all of my changes directly relate to this change? 160 | - [ ] Did I rebase the upstream master branch after I finished all my 161 | work? 162 | - [ ] Did I write a clear pull request message detailing what changes I made? 163 | - [ ] Did I get a code review? 164 | - [ ] Did I make any requested changes from that code review? 165 | 166 | If you follow all of these guidelines and make good changes, you should have 167 | no problem getting your changes merged in. 168 | 169 | 170 | 171 | [style guide]: https://github.com/hackreactor-labs/style-guide 172 | [n-queens]: https://github.com/hackreactor-labs/n-queens 173 | [Underbar]: https://github.com/hackreactor-labs/underbar 174 | [curriculum workflow diagram]: http://i.imgur.com/p0e4tQK.png 175 | [cons of merge]: https://f.cloud.github.com/assets/1577682/1458274/1391ac28-435e-11e3-88b6-69c85029c978.png 176 | [Bookstrap]: https://github.com/hackreactor/bookstrap 177 | [Taser]: https://github.com/hackreactor/bookstrap 178 | [tools workflow diagram]: http://i.imgur.com/kzlrDj7.png 179 | [Git Flow]: http://nvie.com/posts/a-successful-git-branching-model/ 180 | [GitHub Flow]: http://scottchacon.com/2011/08/31/github-flow.html 181 | [Squash]: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html 182 | -------------------------------------------------------------------------------- /STYLE-GUIDE.md: -------------------------------------------------------------------------------- 1 | ### Indentation 2 | 3 | When writing any block of code that is logically subordinate to the line immediately before and after it, that block should be indented two spaces more than the surrounding lines 4 | 5 | * Do not put any tab characters anywhere in your code. You would do best to stop pressing the tab key entirely. 6 | * Increase the indent level for all blocks by two extra spaces 7 | * When a line opens a block, the next line starts 2 spaces further in than the line that opened 8 | 9 | ```javascript 10 | // good: 11 | if(condition){ 12 | action(); 13 | } 14 | 15 | // bad: 16 | if(condition){ 17 | action(); 18 | } 19 | ``` 20 | 21 | * When a line closes a block, that line starts at the same level as the line that opened the block 22 | ```javascript 23 | // good: 24 | if(condition){ 25 | action(); 26 | } 27 | 28 | // bad: 29 | if(condition){ 30 | action(); 31 | } 32 | ``` 33 | 34 | * No two lines should ever have more or less than 2 spaces difference in their indentation. Any number of mistakes in the above rules could lead to this, but one example would be: 35 | 36 | ```javascript 37 | // bad: 38 | transmogrify({ 39 | a: { 40 | b: function(){ 41 | } 42 | }}); 43 | ``` 44 | 45 | * use sublime's arrow collapsing as a guide. do the collapsing lines seem like they should be 'contained' by the line with an arrow on it? 46 | 47 | 48 | ### Variable names 49 | 50 | * A single descriptive word is best. 51 | 52 | ```javascript 53 | // good: 54 | var animals = ['cat', 'dog', 'fish']; 55 | 56 | // bad: 57 | var targetInputs = ['cat', 'dog', 'fish']; 58 | ``` 59 | 60 | * Collections such as arrays and maps should have plural noun variable names. 61 | 62 | ```javascript 63 | // good: 64 | var animals = ['cat', 'dog', 'fish']; 65 | 66 | // bad: 67 | var animalList = ['cat', 'dog', 'fish']; 68 | 69 | // bad: 70 | var animal = ['cat', 'dog', 'fish']; 71 | ``` 72 | 73 | * Name your variables after their purpose, not their structure 74 | 75 | ```javascript 76 | // good: 77 | var animals = ['cat', 'dog', 'fish']; 78 | 79 | // bad: 80 | var array = ['cat', 'dog', 'fish']; 81 | ``` 82 | 83 | 84 | ### Language constructs 85 | 86 | * Do not use `for...in` statements with the intent of iterating over a list of numeric keys. Use a for-with-semicolons statement in stead. 87 | 88 | ```javascript 89 | // good: 90 | var list = ['a', 'b', 'c'] 91 | for(var i = 0; i < list.length; i++){ 92 | alert(list[i]); 93 | } 94 | 95 | // bad: 96 | var list = ['a', 'b', 'c'] 97 | for(var i in list){ 98 | alert(list[i]); 99 | } 100 | ``` 101 | 102 | * Never omit braces for statement blocks (although they are technically optional). 103 | ```javascript 104 | // good: 105 | for(key in object){ 106 | alert(key); 107 | } 108 | 109 | // bad: 110 | for(key in object) 111 | alert(key); 112 | ``` 113 | 114 | * Always use `===` and `!==`, since `==` and `!=` will automatically convert types in ways you're unlikely to expect. 115 | 116 | ```javascript 117 | // good: 118 | 119 | // this comparison evaluates to false, because the number zero is not the same as the empty string. 120 | if(0 === ''){ 121 | alert('looks like they\'re equal'); 122 | } 123 | 124 | // bad: 125 | 126 | // This comparison evaluates to true, because after type coercion, zero and the empty string are equal. 127 | if(0 == ''){ 128 | alert('looks like they\'re equal'); 129 | } 130 | ``` 131 | 132 | * Don't use function statements for the entire first half of the course. They introduce a slew of subtle new rules to how the language behaves, and without a clear benefit. Once you and all your peers are expert level in the second half, you can start to use the more (needlessly) complicated option if you like. 133 | 134 | ```javascript 135 | // good: 136 | var go = function(){...}; 137 | 138 | // bad: 139 | function stop(){...}; 140 | ``` 141 | 142 | 143 | ### Semicolons 144 | 145 | * Don't forget semicolons at the end of lines 146 | 147 | ```javascript 148 | // good: 149 | alert('hi'); 150 | 151 | // bad: 152 | alert('hi') 153 | ``` 154 | 155 | * Semicolons are not required at the end of statements that include a block--i.e. `if`, `for`, `while`, etc. 156 | 157 | 158 | ```javascript 159 | // good: 160 | if(condition){ 161 | response(); 162 | } 163 | 164 | // bad: 165 | if(condition){ 166 | response(); 167 | }; 168 | ``` 169 | 170 | * Misleadingly, a function may be used at the end of a normal assignment statement, and would require a semicolon (even though it looks rather like the end of some statement block). 171 | 172 | ```javascript 173 | // good: 174 | var greet = function(){ 175 | alert('hi'); 176 | }; 177 | 178 | // bad: 179 | var greet = function(){ 180 | alert('hi'); 181 | } 182 | ``` 183 | 184 | # Supplemental reading 185 | 186 | ### Code density 187 | 188 | * Conserve line quantity by minimizing the number lines you write in. The more concisely your code is written, the more context can be seen in one screen. 189 | * Conserve line length by minimizing the amount of complexity you put on each line. Long lines are difficult to read. Rather than a character count limit, I recommend limiting the amount of complexity you put on a single line. Try to make it easily read in one glance. This goal is in conflict with the line quantity goal, so you must do your best to balance them. 190 | 191 | ### Comments 192 | 193 | * Provide comments any time you are confident it will make reading your code easier. 194 | * Be aware that comments come at some cost. They make a file longer and can drift out of sync with the code they annotate. 195 | * Comment on what code is attempting to do, not how it will achieve it. 196 | * A good comment is often less effective than a good variable name. 197 | 198 | 199 | ### Padding & additional whitespace 200 | 201 | * Generally, we don't care where you put extra spaces, provided they are not distracting. 202 | * You may use it as padding for visual clarity. If you do though, make sure it's balanced on both sides. 203 | 204 | ```javascript 205 | // optional: 206 | alert( "I chose to put visual padding around this string" ); 207 | 208 | // bad: 209 | alert( "I only put visual padding on one side of this string"); 210 | ``` 211 | 212 | * You may use it to align two similar lines, but it is not recommended. This pattern usually leads to unnecessary edits of many lines in your code every time you change a variable name. 213 | 214 | ```javascript 215 | // discouraged: 216 | var firstItem = getFirst (); 217 | var secondItem = getSecond(); 218 | ``` 219 | 220 | * Put `else` and `else if` statements on the same line as the ending curly brace for the preceding `if` block 221 | ```javascript 222 | // good: 223 | if(condition){ 224 | response(); 225 | }else{ 226 | otherResponse(); 227 | } 228 | 229 | // bad: 230 | if(condition){ 231 | response(); 232 | } 233 | else{ 234 | otherResponse(); 235 | } 236 | ``` 237 | 238 | 239 | 240 | ### Working with files 241 | 242 | * Do not end a file with any character other than a newline. 243 | * Don't use the -a or -m flags for `git commit` for the first half of the class, since they conceal what is actually happening (and do slightly different things than most people expect). 244 | 245 | ```shell 246 | # good: 247 | > git add . 248 | > git commit 249 | [save edits to the commit message file using the text editor that opens] 250 | 251 | # bad: 252 | > git commit -a 253 | [save edits to the commit message file using the text editor that opens] 254 | 255 | # bad: 256 | > git add . 257 | > git commit -m "updated algorithm" 258 | ``` 259 | 260 | 261 | ### Opening or closing too many blocks at once 262 | 263 | * The more blocks you open on a single line, the more your reader needs to remember about the context of what they are reading. Try to resolve your blocks early, and refactor. A good rule is to avoid closing more than two blocks on a single line--three in a pinch. 264 | 265 | ```javascript 266 | // avoid: 267 | _.ajax(url, {success: function(){ 268 | // ... 269 | }}); 270 | 271 | // prefer: 272 | _.ajax(url, { 273 | success: function(){ 274 | // ... 275 | } 276 | }); 277 | ``` 278 | 279 | 280 | ### Variable declaration 281 | 282 | * Use a new var statement for each line you declare a variable on. 283 | * Do not break variable declarations onto mutiple lines. 284 | * Use a new line for each variable declaration. 285 | * See http://benalman.com/news/2012/05/multiple-var-statements-javascript/ for more details 286 | 287 | ```javascript 288 | // good: 289 | var ape; 290 | var bat; 291 | 292 | // bad: 293 | var cat, 294 | dog 295 | 296 | // use sparingly: 297 | var eel, fly; 298 | ``` 299 | 300 | ### Capital letters in variable names 301 | 302 | * Some people choose to use capitalization of the first letter in their variable names to indicate that they contain a [class](http://en.wikipedia.org/wiki/Class_(computer_science\)). This capitalized variable might contain a function, a prototype, or some other construct that acts as a representative for the whole class. 303 | * Optionally, some people use a capital letter only on functions that are written to be run with the keyword `new`. 304 | * Do not use all-caps for any variables. Some people use this pattern to indicate an intended "constant" variable, but the language does not offer true constants, only mutable variables. 305 | 306 | 307 | ### Minutia 308 | 309 | * Don't rely on JavaScripts implicit global variables. If you are intending to write to the global scope, export things to `window.*` explicitly instead. 310 | 311 | ```javascript 312 | // good: 313 | var overwriteNumber = function(){ 314 | window.exported = Math.random(); 315 | }; 316 | 317 | // bad: 318 | var overwriteNumber = function(){ 319 | exported = Math.random(); 320 | }; 321 | ``` 322 | 323 | * For lists, put commas at the end of each newline, not at the beginning of each item in a list 324 | 325 | ```javascript 326 | // good: 327 | var animals = [ 328 | 'ape', 329 | 'bat', 330 | 'cat' 331 | ]; 332 | 333 | // bad: 334 | var animals = [ 335 | 'ape' 336 | , 'bat' 337 | , 'cat' 338 | ]; 339 | ``` 340 | 341 | * Avoid use of `switch` statements altogether. They are hard to outdent using the standard whitespace rules above, and are prone to error due to missing `break` statements. See [this article](http://ericleads.com/2012/12/switch-case-considered-harmful/) for more detail. 342 | 343 | * Prefer single quotes around JavaScript strings, rather than double quotes. Having a standard of any sort is preferable to a mix-and-match approach, and single quotes allow for easy embedding of HTML, which prefers double quotes around tag attributes. 344 | 345 | ```javascript 346 | // good: 347 | var dog = 'dog'; 348 | var cat = 'cat'; 349 | 350 | // acceptable: 351 | var dog = "dog"; 352 | var cat = "cat"; 353 | 354 | // bad: 355 | var dog = 'dog'; 356 | var cat = "cat"; 357 | ``` 358 | 359 | 360 | ### HTML 361 | 362 | * Use classes for styles only. Use [data behaviors](http://blog.bigbinary.com/2012/10/10/data-behavior.html) or in JavaScript. 363 | 364 | ```html 365 | 366 | 367 | 368 | 369 | 370 | ``` 371 | 372 | * Do not include a `type=text/javascript"` attribute on script tags 373 | 374 | ```html 375 | 376 | 377 | 378 | 379 | 380 | ``` 381 | --------------------------------------------------------------------------------