mirror of
https://github.com/TryGhost/Ghost.git
synced 2024-11-29 15:12:58 +03:00
12729bb469
https://github.com/TryGhost/Admin/pull/2286 - `session.authenticate()` returns from it's promise as soon as the authenticate request is completed but it was assumed that it returned after the `session.handleAuthentication()` promise was also completed. A side-effect of that was that depending on network timing, the setup flow could transition to the dashboard before we had loaded all of the necessary user, config, and settings requests - normally that's not a problem because `handleAuthentication()` kicks off a transition once authentication is fully complete, in the setup flow we're handling the transition manually so need a way to manage the full async flow from outside of the session service - it didn't show up as a problem previously because the setup flow transitioned to a third setup screen that didn't require all of the post-auth data to exist - moved the async parts of `session.handleAuthentication()` into a task and updated to return the currently running task instance if one was already running - lets code that is relying on the full authentication flow to have completed call `await this.session.handleAuthentication()` without causing a double-load of the post-auth API requests - updated setup flow - removed manual `session.populateUser()` call as that was a workaround for the async timing issue and caused a double-fetch of the current user API endpoint - added an `await this.session.handleAuthentication()` call to the manual post-auth handler so we don't transition until the full auth flow is complete |
||
---|---|---|
.. | ||
adapters | ||
authenticators | ||
components | ||
controllers | ||
errors | ||
helpers | ||
initializers | ||
mixins | ||
models | ||
modifiers | ||
routes | ||
serializers | ||
services | ||
session-stores | ||
styles | ||
templates | ||
transforms | ||
transitions | ||
utils | ||
validators | ||
app.js | ||
index.html | ||
README.md | ||
router.js | ||
transitions.js |
Ghost Admin Client
Ember.js application used as a client-side admin for the Ghost blogging platform. This readme is a work in progress guide aimed at explaining the specific nuances of the Ghost Ember app to contributors whose main focus is on this side of things.
CSS
We use pure CSS, which is pre-processed for backwards compatibility by Myth. We do not follow any strict CSS framework, however our general style is pretty similar to BEM.
Styles are primarily broken up into 4 main categories:
- Patterns - are base level visual styles for HTML elements (eg. Buttons)
- Components - are groups of patterns used to create a UI component (eg. Modals)
- Layouts - are groups of components used to create application screens (eg. Settings)
All of these separate files are subsequently imported and compiled in app.css
.
Front End Standards
- 4 spaces for HTML & CSS indentation. Never tabs.
- Double quotes only, never single quotes.
- Use tags and elements appropriate for an HTML5 doctype (including self-closing tags)
- Adhere to the Recess CSS property order.
- Always a space after a property's colon (.e.g, display: block; and not display:block;).
- End all lines with a semi-colon.
- For multiple, comma-separated selectors, place each selector on its own line.
- Use js- prefixed classes for JavaScript hooks into the DOM, and never use these in CSS as per Slightly Obtrusive JavaSript
- Avoid over-nesting CSS. Never nest more than 3 levels deep.
- Use comments to explain "why" not "what" (Good: This requires a z-index in order to appear above mobile navigation. Bad: This is a thing which is always on top!)