themeblvd / backroad Goto Github PK

View Code? Open in Web Editor NEW

26.0 26.0 4.0 7.63 MB

Headless CMS framework, built on the MERN stack.

JavaScript 84.35% CSS 11.11% HTML 4.55%

backroad's People

Contributors

Stargazers

Watchers

Forkers

mustfeez silentashish ctulu82 ozgurmuraterhan

backroad's Issues

Content type classification

At some point, it would be cool to add some sort of grouping aspect to the content API.

Much @todo here...

The need for this is not immediately crucial, as developers already can create some field for a content type and then easily query it through the public API.

For example:

app.content.add({
  id: 'movie',
  name: 'Movie',
  endpoint: 'movies',
  pluralName: 'Movies',
  fields: [
    {
      id: 'desc',
      name: 'Movie Description',
      help: 'Enter a description',
      type: 'textarea'
    },
    {
      id: 'genre',
      name: 'Movie Genre',
      type: 'select',
      options: ['Action', 'Romance', 'Comedy']
    }
  ]
});

In the above example, the genre field could be considered a grouping, and one can currently already query the articles with a specific value for that field like this:

/api/v1/movies/?genre=Action

Endpoints `/admin` and `/install` should be customizeable

When the application starts getting some real-world use, I can imagine there are going to be security concerns with not being able to customize the URL at which admin panel is accessed.

In the first few days of development, it was designed that these endpoints were customizable when configuring the primary backroad() object. However, as things grew I ran into some issues where I was having trouble relaying to the client-side pieces of the application what that current dynamic endpoint was.

For example, I was having issues with routing in the admin React application, because I didn't have a way to get that specified /admin base endpoint configured on the server-side of things by the developer creating the backroad() object. So this inevitably was changed and the routes became hard-coded to /admin and /install.

However, since that point, other similar issues kept creeping up, which suggested some things needed to be changed about the architecture of things. The general issue was passing dynamically created things from the developer using the framework (like content types, general configuration settings, etc) down to client-side applications.

To eventually solve this general architectural issue, I ended up turning to server-side rendering. The index.html file is now rendered from a Handlebars template before being served to the client, where a configuration object with everything the client needs is inserted in a big JSON object printed right there in the <head>.

... So that was a longe explanation to say we can now easily make /admin and /install endpoints customizable by the developer. All we need to do is add them to server-side rendered backroad JSON object that gets rendered in the client's HTML file. That can then replace any hard-coded instances of admin within the client-side application.

Improve behavior of deleting all items from a management table

Currently, when a management table (i.e. users or content of a specific type) is empty, there's a nice little message saying that no content has been created, instead of showing an empty table.

However, when presented with a table of items, if you delete them all, you see the blank table. After deleting the last item, this should ideally re-render the table to display that nicely formatted message the user would now see if they navigated away and came back (or refreshed the route).

Remove configuration from Redux store

Now that we're server-side rendering all of the configuration data into index.html of the admin client app, we no longer need to make an API request to get that data. And with the utility functions added at /utils/data.js it no longer needs to be a part of the state of the Redux store.

So the entire reducer in /admin/src/store/config.js can be removed.

User role needs to be editable

Currently an admin user is created when installing the application. And only admin role users can manage users. But, there's no way for an admin user to create another admin user.

When creating a new user or editing a new user, there needs to be an option to select that user's role.

However, remember that while an editor role user cannot manage users, they can edit their own profile information. The client-side application uses the same form component for this as when an admin is managing users. So there needs to be a check here to not display that new role field.

Note that because this always planned to be an eventual feature, there's already a precaution on the server-side of things that doesn't allow a role field value to get passed when updating a user, if the user is an editor updating their own profile.

Add editor field types

Use Slate to add rich-text and markdown field types.

Initial Documentation

@todo ... brainstorm readme.md for 1.0.0 release.

New admin user should be logged in immediately after signup

Currently after the first admin signs up, they’re redirected to login. Instead, can they already be logged in?

The install and admin are two separate client side apps, served from separate server routes. So we’ll need to configure the install route to send back the token so the client can store it before the redirect happens.

Settings API

This will be the third and final high-level feature Back Road needs for the initial 1.0.0 release. We've got the ability to manage users and content. And finally, the user needs to be able to edit general settings.

Primary Objective

Developers will be able to add groups of settings.
A group of settings will have an id, name, and set of fields.
A group of settings will display as a menu item under "Configure" in the admin client.

Why a settings "group" and not a settings "page"?

For now I'd like to not get too hung up on this. Currently, the application doesn't do a whole lot, and so there's room to add settings groups as individual pages, giving everything more room to breathe. But in the future, if there were more items getting added to that "Configure" section, we might want to condense all settings groups to tabs of a single view (for example).

So internally, we'll refer to these as groups and not pages, views, etc. That way, the idea of groups of settings can then be implemented in a variety of different ways in the future.

API Structure

With that said, similar to changes made in #4 in the content API, we can follow this pattern of allowing methods that accomplish the primary objective of the API to be implicitly named.

So for example instead of:

app.settings.addGroup({ ... })

Adding a group will look like:

app.settings.add({ ... })

And it will be assumed that implicitly named methods like add(), remove(), etc, refer to modifying these groups of settings.

More helpful, crawlable base for /api endpoint

Currently, the public API produced from the CMS isn't all that helpful if you don't know the exact routes for your GET requests.

I would eventually like to see things be more helpful. For example, if I hit /api it should tell me all available routes from there, which would currently be /v1.

And if I hit a GET request to /api/v1/ instead of not returning anything, it could tell me all of the available routes from there, which would be for content type routes, users, etc.

I imagine SEO folks would say this is better for Google indexing, as well.

Rename "contentTypes" API to "content"

Currently, one of the key features, and base principles, of the framework is to add types of content that can be managed by the end-user.

The current API for this is named contentTypes. For example:

const app = backroad();

app.contentTypes.add({...});

I believe this is a bit limiting for future grown of that particular segment of the API (i.e. around configuring content). I would prefer to see it named something more general and simple like content.

However, with that said adding a content "type" is still the base of everything. So I think it would still be acceptable that INSTEAD of this:

app.content.addType({...});

We end up something like this:

app.content.add({...});

Having the method add() is arguably too implicitly named; however, I believe it's easiest to document to developers and it doesn't need to be explicit because this is all formed around it being the "content type API".

Later, things that aren't specificlly a content type could theoretically be named more explicitly like:

app.content.addGroup({...}); // Maybe a method for creating taxonomies?

Add subtle animated transitions to primary view changes

This transition animation should have at least some figurative representation of the space of the application, where these primary views are stacked on top of each other.

To be more direct, I'm thinking a subtle transition where when views enter, they fade in and shift down very slightly. When views leave they fade out and shift down slightly.

Begin thinking about reserved names

In moving ahead with #6, and we start growing other functionality and potentially clashing endpoints we should start thinking about implementing reserved name lists.

For example, if #6 adds /first, /last and /count endpoints to querying users, we could potentially have clash because I've chosen to allow users to be queried by the username like:

/api/v1/users/<username>/

So if the following query brings back the count of users:

/api/v1/users/count/

Then, a user created named count would cause some issues.

To sum up, we need a reserved names list that will apply to usernames and article slugs when being created by the end-user. To start:

['first', 'last', 'count']

A user should not be able to delete themselves

Simply put, an admin user should not be able to delete themselves. I believe it's a bug that this is currently possible.

Since the application uses the existence of at least one admin user to determine if it's installed or not, you shouldn't be able to implicitly uninstall the application from within itself.

And note that when the application is "uninstalled" the admin panel becomes inaccessible, as the server will continue to redirect to the installation client, until that process is finished.

If an admin user (in most cases, the developer setting up the application) wants a new username, they can either (1) change it in the database or (2) create a new admin role user, login under that account, and then delete the original.

Note that #11 needs to be completed for option 2 above.

Confirmation prompt system

The first need for a confirmation prompt is #14, but inevitably there will be more cases like this. We need an easy system for implementing these. After a bit of research, I think this would be a great NPM package to try out:

https://www.npmjs.com/package/react-confirm-alert

It has a nice option for configuring it with custom markup. So, we could implement a customized instance of it through a wrapper function in /utils. This would provide simple use within other components in our application and make it easy to switch to something else in the future if needed (whether it be custom solution or another NPM package).

Help developers with configuration string formatting in content API

Consider the following example of adding a content type:

const app = backroad();

app.content.add({
  id: 'blog_post', // Singular, snake-cased.
  name: 'Blog Post', // Singular, human-readable.
  endpoint: 'blog-posts', // Plural, hyphenated URL slug.
  pluralName: 'Movies', // Plural, human-readable.
  fields: []
});

There's quite a bit going on there in terms of knowing how to format each string. We can definitely add some formatting functions to /lib/utils/formattings.js that will help with ensuring these strings are passed to the content API in the correct format.

Some helper methods might include:

toSlug() - Like blog-posts, Already exists!
toSnakeCase() - Like blog_post.
toTitle() - Capitalize first letter of any words like blog post to Blog Post.

And then we can better utilize these within the content API to ensure things are formatted properly with the content types that are registered.

Need confirmation prompt when deleting user

When deleting a user, there needs to be a warning prompt before proceeding.

Add helpful endpoints to public API for content types

I'm thinking ...

/api/v1/{content-type}/count -- Total number of articles.
/api/v1/{content-type}/first -- First article of content type.
/api/v1/{content-type}/last -- Last article of content type.

Add footer and copyright info

There will be a simple <Footer> component to be most likely added to the bottom of each primary view, so it can be scrolled to and be less obtrusive.

Simplify login page

Simplify the login page and match the look more closely to the installation page.