tivac / crucible Goto Github PK

When viewing all the entries for a schema it should be paginated.

It adds SIX HUNDRED KILOBYTES to the size of the unminified bundle.

That is without source maps, cripes.

Almost certainly tied to my changes to make saving manual, need to investigate ASAP.

So it's easy to check on what you've done.

Because the current behavior is bad.

Should also settle on calling them "Content Type" anywhere they appear.

Could really use both a UX & a UI pass.

nav.js still has lots of legacy pagination code, it should all be removed.

Simplify this thing.

EDITED: This used to talk about unique names, now after #104 has landed it's all about unique slugs.

Would be potentially worthwhile to keep tabs of things users have edited in some sort of order so we can show them recency info.

Could just do it in local storage, but might as well shove it into Firebase since we're already wired up to it and they're (potentially) authed. Wouldn't track that if they aren't authed, obviously.

Right now the key for a schema input is also used for the label, but may want to have different values.

{
  "What is your name?" : {
    type : "text",
    key  : "name"
  }
}

This does make is less apparent when you've stomped on a previous input:

{
  name : "text",
  "What is your real name?" : {
    type : "text",
    key  : "name"
  }
}

Might be valuable to be able to say "Field B should only show up if Field A is Value C".

It keeps coming back up, I'm a bit wary of it though. Could be super-useful, could also be a bit of a slippery slope towards self-aware schemas.

Firebase offers this but only on their $150/month plan.

Automated backups are cooler, but perhaps a button to backup to S3 would suffice for now.
Might be nice to store the last backup date, and nag users if it's been more than 5 days.

If you don't specify the auth type currently you're still forced to /login when attempting to load the page. That check needs to be smarter.

Broke 'em in the transition to the SVG icons, will need to figure out how to fix that.

Options are sticking w/ generated content or including a <svg> tag, basically. Should be straightforward.

This was removed in 7efcee1.

http://purecss.io/layouts/email/ seems like a good inspiration.

Would be useful to be able to search for content by name, I assume.

Currently it appears as "Loading...".

Just rip it all out.

Not sure if this was never the intention (in which case the readme needs an update), or just doesn't yet work.

{
  type : "select",
  options : {
    one : "one", // doesn't work
    two : {
      value : "two" // works
  }
}

They should act like radio, IMO.

Everyone knows that any good home-spun CMS needs a natty logo to go with the cool name.

I suggest that we hit up some ANet Photoshop wizards to come up with something based on this:

I would also be okay with someone coming up with a slogan that has something to do with pouring molten hot content.

We should update a local data representation, then sync that to firebase every so often (5s-ish?). Sometimes going out to firebase is just too laggy.

When the firebase data updates we can use lodash.assign to merge them back together, with local data splatting over the firebase data to ensure that local edits aren't lost. This isn't 100% safe if multiple people are editing the same content at the same time, but it's as close as we've got w/o doing something much more complicated.

It's really ugly 👎

Don't forget the ability to group them!

We've been using Remarkable in GW.com, but perhaps there's something better.

They complicate styling, we should just remove 'em.

It's already got a route, but it needs some UI somewhere. Probably in the nav bar?

In an ideal world we'd support users who wanted to author content on any device. Low priority.

Should have a standardized way to provide a preview URL when defining a schema, so that users can have a straight-forward "Preview" button on every piece of content they edit.

It'd depend on the back-end systems doing the right thing, so this may be problematic in practice.

Throws a JS error current.items is undefined from listings.js

Sometimes you can load the homepage w/o having to login, which seems busted. Need to track it down.

Instead of building a "proper" permissions system, we should just make it less likely that someone using it will end up editing a schema on accident.

In the long term this should live in a new place, but for now needing to know to add /edit to the end of a URL is "good enough".

Would be helpful when you want to force someone to make a conscious decision:

{
  "type*" : "select",
  options : {
    nag : {
        selected : true,
        disabled : true,
        value    : "Please make a section"
      },
    one : {
        value : "option 1"
      },
    two : {
        value : "option 2"
      }
  }
}

It can just grab it from the URL since it's only ever used when the URL has a schema param in it.

Probably using ajv?

Pretty much what the title says.

Crucible supports a really simple versioning scheme, there should be UI that exposes past revisions, let's you view their data (BUT NOT EDIT), and replace the current revision w/ one from the past (implicitly saving the current revision as a new item on the revisions list).

Visual diffing would be interesting but that's a huge rabbit hole I'm not really ready to fall down just yet. Also probably not so useful as to be worth the time it'd take right now.

All content entries should have the option to set an unpublish date field, similar to the publish field.
Every piece of content won't benefit from this, but will be nice for those that do (news posts, sidebars, CTA features). The two fields can be used together without needing an additional publish state field.

Various states:

https://github.com/tivac/crucible/blob/master/src/pages/content-edit/publishing.js

Content table should be sortable by some form of fields.

Name/Created/Updated at the very least.

Right now the delete button is there but non-functional. Should almost certainly have a "confirm" requirement.

Need to figure out what should be on the home page, what is useful for a user?

Right now layout reserves space for the nav component, but IMO it shouldn't. Layout should only care about the left-most nav and the content area beyond. Pages should show the sub-nav if they want it (since only content-edit does). Right now they're too coupled.