I will be accepting up to one pull request per day on this project.
View the result at thepracticaldev.github.io/1pr.
The project's structure is pretty simple.
stylesheets/
directoryscripts/
directoryvendor/
directory, which is ignored by the linters (see Testing below).When contributing, please try to follow the coding standards so we have nice looking code that's easy to follow for everyone.
Where possible, use an editor (or a plugin for your editor) that supports editorconfig.
The editorconfig file should set your editor to the following settings automatically:
Tab width is not defined in the editorconfig, so each deveveloper can set their editor's tab width to what they're most comfortable with.
let
and const
where applicable, to keep the scope of your variables specific. Don't know what scope is or what let
does? Check out this article.lowerCamelCase
for variable names (not snake_case
)The project contains the files .htmlhintrc
, .csslintrc
and .jshintrc
with configuration for the respective testing utilities.
To install the testing utilities locally, simply install Node.js and then use npm (bundled with Node.js) to install the utilities:
npm install --global htmlhint csslint jshint
Run the HTML validator with:
htmlhint
onclick=""
)Run the CSS validator with:
csslint stylesheets
!important
outline: none
unless you have a :focus
rule on the same element to replace the outlineRun the Javascript validator with:
jshint scripts
===
and !==
for type safetyArray
or Date
)1pr is backed by a Firebase database. This allows you to save and share data armed with just the knowledge of JSON rather than having to understand structuring a database or sql etc..
To set up a test database and add yourself as administrator:
create a Firebase account and project
replace the config details in scripts\database\config.js
with the config details shown in the Firebase console
copy the contents of scripts\database\firebase-rules.json
into the database rules section of the console
(Re-do this every time you pull new changes into your fork that change the rules file)
under the authentication section of the console, enable GitHub authentication (follow the instructions there)
(optionally add your github.io subdomain or other domains where you can access your site as an authorised OAuth redirect domain)
serve your files
navigate to your 1pr homepage
click the sign in button in the sidebar to sign in with GitHub and generate a database account for yourself
go to the users panel of the authentication section of the Firebase console and copy the uid
for your newly-generated account
go to the data panel of the database section and:
admins
as a child of the root nodeuid
into the name of that sub-node and add a value of truego back to your 1pr page and refresh.
click the newly-visible Manage Web App link
Click run migrations to apply all database changes to your Firebase database
(Re-run this every time you pull new changes into your fork that change the database)
To develop with the database:
Use the documentation to find out how to save and load data
By default the rules only allow administrators to edit the database, so make sure you've given yourself that role
This is important - Firebase allows connections from localhost so (given the connection details are public) anyone could serve their own script that reads and writes to the database maliciously
Make a new top-level node for each feature (unless it particularly makes sense not to)
Remember to update the rules to allow non-admins to use your feature, though be restrictive rather than permissive
Remember to test those rules using the simulator build into the rules interface
Record the steps you take modifying the structure and data within the database in a migration:
Open up scripts\database\migrations.js
Find the end of the migrations
array
Add a new object, following the pattern of the existing migrations, i.e.
{
//unique identifier for the migration
name: "doNothing",
//talk about what your changes do
description: "Does nothing of substance. Does add to the migration history.",
//function that returns a promise
// (or other thenable object) that
// enacts the data manipulation to
// achieve what you want to do
doMigration: function(){return Promise.Resolve();}
}
Test your migration by using the button on the admin page
There's no mechanism to roll back migrations yet, so testing multiple times requires deleting all but the admins
node from the database and rerunning all migrations again
Add the class signed-out
to any elements you want to be visible when the user isn't signed in
Add the classes signed-in
and hidden
to the elements you want to show when the user is signed in
Add the classes signed-in-admin
and hidden
on top of the regular signed-in hidden
to the elements you want to show when the user is signed in as an admin