SocialStack - User contributions [en-gb]

Role Permits

2024-04-26T16:08:27Z

Ablewhite:

Role permits are a mechanism which allow any content to be visible based on role. This is most frequently used by pages to make multiple variations of a page. The page displayed to the user is ultimately the one which the permission system selected for them.

This is useful for multiple reasons: Firstly, it allows you to use the editor for each role variation of the content. You don't need to try and be in the context of a given role when making changes to a page, for example. Second, the content for other roles is not present in the source of the page, keeping that content safer if it is, for example, paid for content.

Role permits are not active for content by default. You must make use of them in your [[Permissions|permission rules]] with "HasRolePermit()". This also means you can use them as part of a more complex permission rule, or invert it if you want your list of roles to represent *excluded* roles:

<syntaxhighlight lang="sql">
!HasRolePermit()
</syntaxhighlight>

Role Permits

2024-04-26T16:04:14Z

Ablewhite:

Role permits are a mechanism which allow any content to be visible based on role. This is most frequently used by pages to make multiple variations of a page. The page displayed to the user is ultimately the one which the permission system selected for them.

This is useful for multiple reasons: Firstly, it allows you to use the editor for each role variation of the content. You don't need to try and be in the context of a given role when making changes to a page, for example. Second, the content for other roles is not present in the source of the page, keeping that content safer if it is, for example, paid for content.

Role permits are not active for content by default. You must make use of them in your [[Permissions|permission rules]] with "HasRolePermits()". This also means you can use them as part of a more complex permission rule, or invert it if you want your list of roles to represent *excluded* roles:

<syntaxhighlight lang="sql">
!HasRolePermits()
</syntaxhighlight>

Role Permits

2024-04-26T16:03:56Z

Ablewhite:

File Uploads

2023-05-26T10:04:06Z

Ablewhite: Added section detailing `file-consistency` API

SocialStack has a mechanism for uploading public or private files. When a file is uploaded, the upload endpoint will return a [[File Refs|file ref]] for the new file, which is then typically the main way to refer to a particular file.

By default, when uploading an image file, it will automatically be resized into a collection of different sizes for convenience. This works on modern image formats like webp too.

If you need video to be handled as well, you can either install the Api/FFmpeg module and ffmpeg on the target servers (ffmpeg is installed by default on all SocialStack cloud servers), or perform remote transcoding with huddle servers. Transcoding video is a very heavy process but usually mandatory if a CDN is involved in your project due to the file size limits of a CDN, and also end users benefit by being able to skip through the video substantially faster.

= Displaying a file uploader =

Use type="file" for a file uploader. When the form is submitted, the value will be the [[File Refs|file ref]]:

<syntaxhighlight lang="javascript">
import Input from 'UI/Input';

...

<Input type="file" name="myFile" label="My File Uploader" />
</syntaxhighlight>

This defaults to storing files in the public file store. If you want them to be private, add the isPrivate prop:

<syntaxhighlight lang="javascript">
import Input from 'UI/Input';

...

<Input type="file" name="myFile" label="My File Uploader" isPrivate />
</syntaxhighlight>

= Making use of an uploaded file =

== On the frontend ==

An uploaded file is represented as a [[File Refs|file ref]] on the frontend - see the [[File Refs|file ref wiki article]] on how to work with those on the frontend.

== In the API ==

As an upload is a content type, you can subscribe to Upload related events to handle when a new file is uploaded. This is often not the easiest to work with though; more on that in a moment:

<syntaxhighlight lang="csharp">

Events.Upload.AfterCreate.AddEventListener(async (Context context, Upload upload) => {

if(upload == null) {
return upload;
}

// Do something with upload here.

return upload;

});

// AfterUpdate, AfterDelete etc

</syntaxhighlight>

However, because this event runs whenever any file is uploaded, there's no context on why it was uploaded. This is fine if you're building something like a transcoder which just cares about file type, but not if you're making something that requires a specific file. Instead, it's recommended to make a custom endpoint which receives a ref for that situation.

For example, the frontend may have a form like this:

<syntaxhighlight lang="csharp">
<Form action="attendee/from-csv" submitLabel="Apply">
<Input type="file" label="Attendee CSV" name="csvRef" isPrivate/>
</Form>
</syntaxhighlight>

When the file is uploaded and the form is submitted, a JSON payload containing a field called csvRef will get posted to the endpoint, and the payload would look something like this:

<syntaxhighlight lang="json">
{
"csvRef": "private:42.csv?s=..."
}
</syntaxhighlight>

From there, a C# asp.net controller method can capture the ref value:

<syntaxhighlight lang="csharp">
[HttpPost("from-csv")]
public async ValueTask FromCsv([FromBody] CsvRefPayload payload)
{
var context = await Request.GetContext();
var csvRef = payload.csvRef; // the string

// Do something fun with the csvRef here! (there's more on handling refs in the API in the file ref wiki).
}

...

public class CsvRefPayload
{
public string csvRef;
}

</syntaxhighlight>

For information on using a ref in the API, see the [[File Refs|file ref wiki page]].

= Upload metadata =

== On the frontend ==

File uploads are a content type (called Upload), meaning all the usual conveniences apply: you can list all uploads, use Loop on them and so on - provided the user has permission to do so.

<syntaxhighlight lang="javascript">

<Loop over='upload'>{anUpload => <>{anUpload.originalName}</>}</Loop>

// Or if you want an array of uploads:

webRequest('upload/list').then(response => {
// response.json.results
})

</syntaxhighlight>

== In the API ==

As with other content types, either use injection or Services.Get to access the UploadService. From there, you can List/ Update and so on the upload you're interested in.

= File Consistency =

When uploading images, SocialStack automatically produces resized versions of each image (along with optionally converting to WEBP format), dependent on the uploader configuration. It is possible however that if configuration settings are subsequently changed, any new image sizes / formats will be unavailable for existing uploads.

To address this, SocialStack provides an API endpoint (<code>/v1/upload/file-consistency</code>) which can be called to ensure all requested image sizes / formats are available for all image uploads. Please note, the use of a local GPU is highly recommended, as this process can take a substantial amount of time. Progress can be viewed via messages logged to the SocialStack API window.

== Updating a specific range of images ==

Use <code>/v1/upload/file-consistency?idRange=[from_id]-[to_id]</code> (e.g. <code>/v1/upload/file-consistency?idRange=1000-1042</code>) to restrict consistency checks for uploads only within the given ID range.

== Forcing image regeneration ==

By default, SocialStack will leave existing images untouched, simply creating new image sizes / formats only when missing. To force the regeneration of images regardless of whether or not they already exist, use <code>/v1/upload/file-consistency?regenBefore=[iso_date]</code> (use <code>new Date().toISOString()</code> to generate a current ISO date).

This will ensure image sizes / formats are recreated, as long as they're dated before the ISO date specified.

Impersonation

2023-01-11T23:09:58Z

Ablewhite:

If you need to switch account, often to debug something, there are two useful endpoints on the API for doing just that. The functionality is only available to admin users and will also refuse any elevation attempts, such as attempting to impersonate a [[Permissions|developer account]] from a [[Permissions|regular admin one]].

= Starting impersonation =

Send a get request to /v1/user/x/impersonate where x is the user's ID. This means you can just navigate to it with your browser, or use webRequest like so:

<syntaxhighlight lang="js">

import webRequest from 'UI/Functions/WebRequest';

function impersonate(userId){

return webRequest('user/' + userId + '/impersonate').then(response => {
window.location = '/';
});
}

</syntaxhighlight>

= Ending impersonation =

Send a get request to /v1/user/unpersonate

= Identifying if someone is impersonating =

The frontend can identify if someone is currently impersonating via a session value called realUser:

<syntaxhighlight lang="js">
const { session, setSession } = useSession();
var { realUser, user } = session;

// If realUser is set and different to user, they are impersonating
var isImpersonating = realUser && (user.id != realUser.id);

</syntaxhighlight>

Styling

2021-11-09T22:54:16Z

Ablewhite: /* Example */

== Introduction ==

All styling within SocialStack uses SASS (https://sass-lang.com/guide). As this is a superset of CSS, any valid CSS can be used, but it's worth taking the time to get to grips with SASS syntax and the built-in functions it provides, as these can both save time and improve the readability of your styles. Please note, SocialStack uses SCSS syntax rather than the old SASS indented syntax (see https://sass-lang.com/documentation/syntax).

=== Filename conventions ===

All SASS stylesheets within a SocialStack project are combined and included within the resulting site. Changing the order in which these files are combined (and thus potentially affecting the cascade, causing overlapping rules to be overridden or not) can be done by adding a value from 1-100 within the filename itself, e.g. <code>foobar.50.scss</code> (SCSS files without a value default to a level of 100).

Styles which include definitions which should be available to the entire project (e.g. SASS variables, mixins, etc) should be prefixed with "global.", e.g. <code>global.variables.scss</code>.

There's no need to minify your styling as this is handled by the compiler.

=== Theme styling ===

[TODO] Styles can be defined at both the theme and component level - theme styles are global and available throughout the SocialStack site.

=== Component styling ===

Each SocialStack component includes optional styling - for instance, running <code>socialstack generate UI/FooBar</code> in a SocialStack project folder will create both <code>UI/FooBar/FooBar.js</code> for the component itself, along with <code>UI/FooBar/FooBar.scss</code> - this can then be used to define component-specific styling.

=== Responsive styling ===

All styling within SocialStack should aim to be responsive and mobile-first (i.e., start with mobile-specific styling and layer other device / resolution overrides on top as necessary). As SocialStack uses the Bootstrap framework by default (https://getbootstrap.com/docs), we can utilise Bootstrap SASS mixins to target specific breakpoints. For instance, the following example will cause the component to show a green background for mobile devices, switching to red when viewed on anything 768px wide or above (defined by the Bootstrap medium or <code>md</code> breakpoint):

<syntaxhighlight lang="scss" line="1">
.foobar {
background: green;
}

@include media-breakpoint-up(md) {
.foobar {
background: red;
}
}
</syntaxhighlight>

This resolves to:

<syntaxhighlight lang="css" line="1">
.foobar {
background: green;
}

@media (min-width: 768px) {
.foobar {
background: red;
}
}
</syntaxhighlight>

Please refer to https://getbootstrap.com/docs/5.1/layout/breakpoints/ for details on which other breakpoints are available.

==== Note ====

<blockquote>Defining multiple <code>@media</code> queries in ascending order is highly recommended in order to avoid unexpected bugs where a "smaller" media query overrides a larger one.</blockquote>

=== Naming conventions ===

Whilst not strictly enforced, the use of the BEM (Block Element Modifier) methodology (https://en.bem.info/methodology) when naming classes is strongly recommended:

* Targetting styles to a class such as <code>foobar__header--secondary</code> is way less brittle than using specific HTML elements (e.g. <code>h2</code>), as changes during development inevitably result in changes to markup

* Descriptive classes defined in this way are both more consistent and descriptive

* Much more obvious which element(s) on the page will be affected

==== Example ====

Taking the following menu design as a guide:

[[File:menu.png||Example design]]

This could be defined with the following markup:

<syntaxhighlight lang="html" line="1">
<nav className="foobar">
<ul className="menu">
{/* home */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
{/* calendar */}
<li className="menu__item">
<a href="#" className="menu__link menu__link--active">
<svg className="menu__icon" ... />
</a>
</li>
{/* video */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
{/* chat */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
</ul>
</nav>
</syntaxhighlight>

Corresponding styles could then be defined as:

<syntaxhighlight lang="scss" line="1">
$menu_background: #000;
$menu_foreground: #fff;
$menu_foreground_inactive: rgba($menu_foreground, .5);
$menu_foreground_hover: rgba($menu_foreground, .75);
$menu_icon_size: 24px;

.foobar {
.menu {
list-style: none;
padding: 0;
background-color: $menu_background;

&__item {
display: inline-block;
}

&__link {
display: flex;
align-items: center;
justify-content: center;
padding: 0 25px;
border-bottom: 4px solid transparent;

&:hover {
border-bottom-color: $menu_foreground_hover;

.menu__icon {
color: $menu_foreground_hover;
}
}

&--active {
border-bottom-color: $menu_foreground;

.menu__icon {
color: $menu_foreground;
}
}
}

&__icon {
width: $menu_icon_size;
height: $menu_icon_size;
color: $menu_foreground_inactive;
}
}
}
</syntaxhighlight>

* Defining variables for values which are used in multiple instances (or which are likely to change) allows for easier editing

* Wrapping all the rules within a parent <code>.foobar</code> block ensures these styles will only affect elements parented by that class (namely, those within this component)

* Use of <code>&__item</code> style concatenation reduces repetitive typing of common elements in class names - in the above example, this would resolve to <code>.menu__item</code>

* Note that we're not using <code>&__icon</code> within the <code>&:hover</code> or <code>&--active</code> blocks - this would result in <code>.menu__link--active__icon</code> and not <code>.menu__link--active .menu__icon</code>

* While stock CSS doesn't allow #RGB values to be used within <code>rgba()</code>, SASS does - here we use <code>rgba($menu_foreground, .5)</code> which resolves to <code>rgba(255, 255, 255, .5)</code> in the resulting CSS

* Note that nesting of rules is kept to a minimum - there's no need to follow the markup structure religiously (e.g. <code>.menu .menu__item .menu__link</code>), as the classnames are descriptive and unique enough

Styling

2021-11-09T22:53:30Z

Ablewhite:

== Introduction ==

All styling within SocialStack uses SASS (https://sass-lang.com/guide). As this is a superset of CSS, any valid CSS can be used, but it's worth taking the time to get to grips with SASS syntax and the built-in functions it provides, as these can both save time and improve the readability of your styles. Please note, SocialStack uses SCSS syntax rather than the old SASS indented syntax (see https://sass-lang.com/documentation/syntax).

=== Filename conventions ===

All SASS stylesheets within a SocialStack project are combined and included within the resulting site. Changing the order in which these files are combined (and thus potentially affecting the cascade, causing overlapping rules to be overridden or not) can be done by adding a value from 1-100 within the filename itself, e.g. <code>foobar.50.scss</code> (SCSS files without a value default to a level of 100).

Styles which include definitions which should be available to the entire project (e.g. SASS variables, mixins, etc) should be prefixed with "global.", e.g. <code>global.variables.scss</code>.

There's no need to minify your styling as this is handled by the compiler.

=== Theme styling ===

[TODO] Styles can be defined at both the theme and component level - theme styles are global and available throughout the SocialStack site.

=== Component styling ===

Each SocialStack component includes optional styling - for instance, running <code>socialstack generate UI/FooBar</code> in a SocialStack project folder will create both <code>UI/FooBar/FooBar.js</code> for the component itself, along with <code>UI/FooBar/FooBar.scss</code> - this can then be used to define component-specific styling.

=== Responsive styling ===

All styling within SocialStack should aim to be responsive and mobile-first (i.e., start with mobile-specific styling and layer other device / resolution overrides on top as necessary). As SocialStack uses the Bootstrap framework by default (https://getbootstrap.com/docs), we can utilise Bootstrap SASS mixins to target specific breakpoints. For instance, the following example will cause the component to show a green background for mobile devices, switching to red when viewed on anything 768px wide or above (defined by the Bootstrap medium or <code>md</code> breakpoint):

<syntaxhighlight lang="scss" line="1">
.foobar {
background: green;
}

@include media-breakpoint-up(md) {
.foobar {
background: red;
}
}
</syntaxhighlight>

This resolves to:

<syntaxhighlight lang="css" line="1">
.foobar {
background: green;
}

@media (min-width: 768px) {
.foobar {
background: red;
}
}
</syntaxhighlight>

Please refer to https://getbootstrap.com/docs/5.1/layout/breakpoints/ for details on which other breakpoints are available.

==== Note ====

<blockquote>Defining multiple <code>@media</code> queries in ascending order is highly recommended in order to avoid unexpected bugs where a "smaller" media query overrides a larger one.</blockquote>

=== Naming conventions ===

Whilst not strictly enforced, the use of the BEM (Block Element Modifier) methodology (https://en.bem.info/methodology) when naming classes is strongly recommended:

* Targetting styles to a class such as <code>foobar__header--secondary</code> is way less brittle than using specific HTML elements (e.g. <code>h2</code>), as changes during development inevitably result in changes to markup

* Descriptive classes defined in this way are both more consistent and descriptive

* Much more obvious which element(s) on the page will be affected

==== Example ====

Taking the following menu design as a guide:

[[File:menu.png||Example design]]

This could be defined with the following markup:

<pre>
<nav className="foobar">
<ul className="menu">
{/* home */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
{/* calendar */}
<li className="menu__item">
<a href="#" className="menu__link menu__link--active">
<svg className="menu__icon" ... />
</a>
</li>
{/* video */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
{/* chat */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
</ul>
</nav>
</pre>

Corresponding styles could then be defined as:

<pre>
$menu_background: #000;
$menu_foreground: #fff;
$menu_foreground_inactive: rgba($menu_foreground, .5);
$menu_foreground_hover: rgba($menu_foreground, .75);
$menu_icon_size: 24px;

.foobar {
.menu {
list-style: none;
padding: 0;
background-color: $menu_background;

&__item {
display: inline-block;
}

&__link {
display: flex;
align-items: center;
justify-content: center;
padding: 0 25px;
border-bottom: 4px solid transparent;

&:hover {
border-bottom-color: $menu_foreground_hover;

.menu__icon {
color: $menu_foreground_hover;
}
}

&--active {
border-bottom-color: $menu_foreground;

.menu__icon {
color: $menu_foreground;
}
}
}

&__icon {
width: $menu_icon_size;
height: $menu_icon_size;
color: $menu_foreground_inactive;
}
}
}
</pre>

* Defining variables for values which are used in multiple instances (or which are likely to change) allows for easier editing

* Wrapping all the rules within a parent <code>.foobar</code> block ensures these styles will only affect elements parented by that class (namely, those within this component)

* Use of <code>&__item</code> style concatenation reduces repetitive typing of common elements in class names - in the above example, this would resolve to <code>.menu__item</code>

* Note that we're not using <code>&__icon</code> within the <code>&:hover</code> or <code>&--active</code> blocks - this would result in <code>.menu__link--active__icon</code> and not <code>.menu__link--active .menu__icon</code>

* While stock CSS doesn't allow #RGB values to be used within <code>rgba()</code>, SASS does - here we use <code>rgba($menu_foreground, .5)</code> which resolves to <code>rgba(255, 255, 255, .5)</code> in the resulting CSS

* Note that nesting of rules is kept to a minimum - there's no need to follow the markup structure religiously (e.g. <code>.menu .menu__item .menu__link</code>), as the classnames are descriptive and unique enough

Styling

2021-11-09T22:26:42Z

Ablewhite: Introduction to styling in SocialStack

== Introduction ==

All styling within SocialStack uses SASS (https://sass-lang.com/guide). As this is a superset of CSS, any valid CSS can be used, but it's worth taking the time to get to grips with SASS syntax and the built-in functions it provides, as these can both save time and improve the readability of your styles. Please note, SocialStack uses SCSS syntax rather than the old SASS indented syntax (see https://sass-lang.com/documentation/syntax).

=== Filename conventions ===

All SASS stylesheets within a SocialStack project are combined and included within the resulting site. Changing the order in which these files are combined (and thus potentially affecting the cascade, causing overlapping rules to be overridden or not) can be done by adding a value from 1-100 within the filename itself, e.g. <code>foobar.50.scss</code> (SCSS files without a value default to a level of 100).

Styles which include definitions which should be available to the entire project (e.g. SASS variables, mixins, etc) should be prefixed with "global.", e.g. <code>global.variables.scss</code>.

There's no need to minify your styling as this is handled by the compiler.

=== Theme styling ===

[TODO] Styles can be defined at both the theme and component level - theme styles are global and available throughout the SocialStack site.

=== Component styling ===

Each SocialStack component includes optional styling - for instance, running <code>socialstack generate UI/FooBar</code> in a SocialStack project folder will create both <code>UI/FooBar/FooBar.js</code> for the component itself, along with <code>UI/FooBar/FooBar.scss</code> - this can then be used to define component-specific styling.

=== Responsive styling ===

All styling within SocialStack should aim to be responsive and mobile-first (i.e., start with mobile-specific styling and layer other device / resolution overrides on top as necessary). As SocialStack uses the Bootstrap framework by default (https://getbootstrap.com/docs), we can utilise Bootstrap SASS mixins to target specific breakpoints. For instance, the following example will cause the component to show a green background for mobile devices, switching to red when viewed on anything 768px wide or above (defined by the Bootstrap medium or <code>md</code> breakpoint):

<pre>
.foobar {
background: green;
}

@include media-breakpoint-up(md) {
.foobar {
background: red;
}
}
</pre>

This resolves to:

<pre>
.foobar {
background: green;
}

@media (min-width: 768px) {
.foobar {
background: red;
}
}
</pre>

Please refer to https://getbootstrap.com/docs/5.1/layout/breakpoints/ for details on which other breakpoints are available.

==== Note ====

<blockquote>Defining multiple <code>@media</code> queries in ascending order is highly recommended in order to avoid unexpected bugs where a "smaller" media query overrides a larger one.</blockquote>

=== Naming conventions ===

Whilst not strictly enforced, the use of the BEM (Block Element Modifier) methodology (https://en.bem.info/methodology) when naming classes is strongly recommended:

* Targetting styles to a class such as <code>foobar__header--secondary</code> is way less brittle than using specific HTML elements (e.g. <code>h2</code>), as changes during development inevitably result in changes to markup

* Descriptive classes defined in this way are both more consistent and descriptive

* Much more obvious which element(s) on the page will be affected

==== Example ====

Taking the following menu design as a guide:

[[File:menu.png||Example design]]

This could be defined with the following markup:

<pre>
<nav className="foobar">
<ul className="menu">
{/* home */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
{/* calendar */}
<li className="menu__item">
<a href="#" className="menu__link menu__link--active">
<svg className="menu__icon" ... />
</a>
</li>
{/* video */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
{/* chat */}
<li className="menu__item">
<a href="#" className="menu__link">
<svg className="menu__icon" ... />
</a>
</li>
</ul>
</nav>
</pre>

Corresponding styles could then be defined as:

<pre>
$menu_background: #000;
$menu_foreground: #fff;
$menu_foreground_inactive: rgba($menu_foreground, .5);
$menu_foreground_hover: rgba($menu_foreground, .75);
$menu_icon_size: 24px;

.foobar {
.menu {
list-style: none;
padding: 0;
background-color: $menu_background;

&__item {
display: inline-block;
}

&__link {
display: flex;
align-items: center;
justify-content: center;
padding: 0 25px;
border-bottom: 4px solid transparent;

&:hover {
border-bottom-color: $menu_foreground_hover;

.menu__icon {
color: $menu_foreground_hover;
}
}

&--active {
border-bottom-color: $menu_foreground;

.menu__icon {
color: $menu_foreground;
}
}
}

&__icon {
width: $menu_icon_size;
height: $menu_icon_size;
color: $menu_foreground_inactive;
}
}
}
</pre>

* Defining variables for values which are used in multiple instances (or which are likely to change) allows for easier editing

* Wrapping all the rules within a parent <code>.foobar</code> block ensures these styles will only affect elements parented by that class (namely, those within this component)

* Use of <code>&__item</code> style concatenation reduces repetitive typing of common elements in class names - in the above example, this would resolve to <code>.menu__item</code>

* Note that we're not using <code>&__icon</code> within the <code>&:hover</code> or <code>&--active</code> blocks - this would result in <code>.menu__link--active__icon</code> and not <code>.menu__link--active .menu__icon</code>

* While stock CSS doesn't allow #RGB values to be used within <code>rgba()</code>, SASS does - here we use <code>rgba($menu_foreground, .5)</code> which resolves to <code>rgba(255, 255, 255, .5)</code> in the resulting CSS

* Note that nesting of rules is kept to a minimum - there's no need to follow the markup structure religiously (e.g. <code>.menu .menu__item .menu__link</code>), as the classnames are descriptive and unique enough

Styling

2021-11-09T21:45:15Z

Ablewhite: Created page with "Introduction All styling within SocialStack uses SASS (https://sass-lang.com/guide). As this is a superset of CSS, any valid CSS can be used, but it's worth taking the time t..."

Introduction

All styling within SocialStack uses SASS (https://sass-lang.com/guide). As this is a superset of CSS, any valid CSS can be used, but it's worth taking the time to get to grips with SASS syntax and the built-in functions it provides, as these can both save time and improve the readability of your styles. Please note, SocialStack uses SCSS syntax rather than the old SASS indented syntax (see https://sass-lang.com/documentation/syntax).

Filename conventions

All SASS stylesheets within a SocialStack project are combined and included within the resulting site. Changing the order in which these files are combined (and thus potentially affecting the cascade, causing overlapping rules to be overridden or not) can be done by adding a value from 1-100 within the filename itself, e.g. foobar.50.scss (SCSS files without a value default to a level of 100).

Styles which include definitions which should be available to the entire project (e.g. SASS variables, mixins, etc) should be prefixed with "global.", e.g. global.variables.scss.

There's no need to minify your styling as this is handled by the compiler.

Theme styling

[TODO] Styles can be defined at both the theme and component level - theme styles are global and available throughout the SocialStack site.

Component styling

Each SocialStack component includes optional styling - for instance, running socialstack generate UI/FooBar in a SocialStack project folder will create both UI/FooBar/FooBar.js for the component itself, along with UI/FooBar/FooBar.scss - this can then be used to define component-specific styling.

File:Menu.png

2021-11-09T21:00:03Z

Ablewhite:

Example menu design

File:Info.png

2021-11-09T15:11:20Z

Ablewhite:

Information icon

File:Warning.png

2021-11-09T15:10:49Z

Ablewhite:

warning icon