prismatik / dendritic-admin Goto Github PK

And remove JSCS while you're at it.

This is pretty simple to have (provided you're on JSX hehe) https://www.npmjs.com/package/chai-jsx

this doesn't have to be elaborate in depth testing. technically you should push towards stateless components. but, a test that makes sure that your component renders and have the content in it will save you hours when you upgrade React to the next major version.

imo this is a must have

I think we can refactor out Creator (remove) and instead we can use what I’ve done in /collections/doc instead - which is mapping data using a schema which generates the form inputs dynamically, and then these are passed as props to Form.

This will solve a couple of things:

• Remove one of the last bits of duplicated schema logic (the calculateInputs method); this now all lives happily in the /lib/transformers/schema.
• Use more modular form components.
• Promote more reusability/portability.
• Better separation of concerns.

So the intention of Creator can now be repurposed as a couple of lines of code.

const inputs = head(mapSchemaToFormInputs(schemaProps, data));
return DOM.div({ className: 'section' }, Form(null, inputs));

There are some method ideas laid down in Creator that we want to carry across and pass into Form such as:

• Submit handler function should be passed as prop eg. Form({ submitHandler: doStuff }, inputs). doStuff would contain an API call most likely to post/put/whatever data. This should be added as defaultProp too.

Couple of ideas I want to put out there regarding API calls:

• Currently native fetch is being used. This doesn't have a wide range of support so I suggest using axios. Axios has official specced promise support and we've used this on several projects so I don't see why we wouldn't keep rolling with it. I don't think we're too tied to an ajax lib, but axios has proved to be little hassle. My next suggestion would help if we did want to change it up later...

I think also we could create /lib/api with a request method (or similar) that we can pass data to which will then use axios. I suggest this so that we can keep our API layer/methods reasonably generic, and if for some reason we need to change axios to superagent or whatever then there is less surface area to tend to.

Also another reason for creating /lib/api is that we could have our request method always convert flat -> deep form properties (if exists) when posted - so this logic is only done in one spot, and not duplicated in form submit handlers. Currently form2js is used to do this.

I see it looking kinda like this:

// /lib/api.js
import axios from 'axios;
import form2js from 'form2js';

export default function request(path, data, opts) {
  const converted = form2js(data);
  return axios(path, converted);
}

Can't remember exactly what the params for axios and form2js are, but you get the picture I think.

Currently the connect/disconnect/listener logic for sockets is living inside each component. This should be pulled out and consolidated into a higher order component for portability, less duplication and ease of understanding.

As we are utilising "classic" React format with .createClass, the HOC will be a little more hefty than with .Component class, but still much more suited than a mixin or a component method.

For this project needs, async fetching requires some info from the state to make those calls, so redux-connect is a better fit as it marries up redux with component async data fetching nicely.

We should make the "id" column a link to it's edit page.

Also at this time we can fix up the related data link, and instead of this being something like "/sheep/123-456-789", it can just be the UUID which again links to that document edit page.

I think we should move the LHS nav up to be a smaller secondary header below the current header - and then make the nav items horizontal and left aligned. This will allow more screen real estate for tabular data (listing documents), and it will keep the content hierarchy consistently stacked between screen sizes (currently it stacks for smaller screens, and splits into columns for larger screens) which is nicer I think.

Currently the UX is a little clunky. We have a "Create" button at the top of each collection, and when clicked this shows a form which pushes the list down. If we have more than say, 6/7 fields in the form, then it becomes a jarring experience as it pushes the content down each time.

I suggest an alternative that we create a separate create page. Keep the "create" button where it is but after selecting it displays only a blank form ready for info to be added. We could also make this similar to the flow of keystone, where once you click "create", it automatically posts to the API and creates a doc, returns the doc and we then use the "id" to redirect to /collections/wolves/:newIdJustGenerated and we are then editing the newly created document.

Thoughts?

I suggest using istanbul.

https://www.npmjs.com/package/husky is awesome. just setup precommit -> run lint and prepush -> run test and you won't have a red build ever again

Seeing as webpack is already in there there's no need for both, we can bundle with webpack instead.

As mentioned in #36 , native fetch should be removed in favour of using /lib/api.

I've noticed that you have either ^ or completely empty deps versions in package.json, that's kind of bad practice as npm will just install the most recent version on every deployment and it also makes it very difficult to track deps updates.

i'd suggest we use the --save-exact to lock the versions in.

React has some great validation rules for props, and also allows custom validation rules and I think we should utilise this as much possible.

It provides us free, built-in validation for any corrupt data that might get put into the API, or messed up with a migration etc.. and this has been one of the main gripes with Keystone. If we can see data throwing errors in the browser console (or perhaps kick that out to the UI in some way) first thing when entering the admin it could save us hours of time attempting to debug busted data.

Ideally, data will be validated/sanitized before it gets into the API, though if it does pass through the keeper then at least we can verify the dodgy bits easily.

This is especially useful for any props that represent a schema - something like react-prop-schema could be used.

At the moment it's just stringified JSON in a textarea because YOLO. It should be a nice hierarchical display like the creator form.

Question is, should is just be the creator form? If you're looking at it, may as well give you the option to edit it.

That way, we could also add this code to the id column of the table display so that you can edit instances of all the records in the table.

Doing that will require a little refactoring in the creator module to allow it to take existing values. They need to be passed around in the recursion it does so that the lineage all makes sense.

Currently there are no client-side routes. The navigation currently uses redux to store a nav.active property so we know which collection we're looking at. react-router can do this in a much nicer way, and give us routes we can use eg. /collections/wolf/1234-567-8901 for reading/editing purposes.

Without routes we'll need to rely on "switch tactics" such as "this var and this var are true so let's show this component". This get's messy quickly when you want to have more than 2-3 components doing things on a page.

At the moment, the listener re-renders the table component every time a new record is received from sockets.io. This is problematic when admin UI is first started as it will re-render the table once for every record received. This should only render table once the initial batch is fully received, and then again on when any further records are received.

Might just be easier to source it from google fonts instead of having a local copy. There's some latency with that, but meh, it's just admin.

... because we should have em. Go with Mocha.

I suggest we should stick to using JSX instead of React API for any redbeard react work. Most of our react projects use JSX, is there any reason we shouldn't use it for this?

form2js kinda works, but it accesses the raw dom to gather up form data where we should be accessing the virtual dom with React - using refs tags. We could do this manually and write a small "form data gatherer" thingy, or we could use something like...

• react-forms: Haven't used this, but it does have schema validation which is a nice added bonus.
• formsy-react: Haven't used this either. Not sure how I feel about installing a module called "formsy"...
• Move our form data to redux and use redux-form. We've used this on a couple of projects, though we are generally trying to restrict the amount of data used in global state.

Currently any failed create operation does not report the error to the admin UI. We should fix this and use the same alert mechanism when we extend to update and delete.

Currently once a new model is created no action is triggered to add this model to the list view.

One potential fix is to...

1. Pass the dispatch function into the creator component
2. Use the dispatch function to update state with the new model
   (this is along the lines of our Ordermentum patterns)

However Dave may have other plans in mind for this, with sockets we can probably just be notified via a change feed that the model has been added and update the List accordingly. Need to confirm approach before this can be worked on.

For components to talk to each other correctly they need to converge into a single render. Currently there are multiple components being rendered to different DOM elements.

I suggest we wrap these in a single main container and have that rendered out. This affects #10, #11 and #12.

Originally this redbeard specific socket listener was built here in the admin, and then it was ported to Hosportal and upgraded over there.

I think it would a good idea to extract this out to it's own component to be used by both redbeard UI and redbeard admin.

The current layout is okay and works, though it would be good to update to make a little more intuitive.

The proposal:

• Inclusion of a left nav which will list available resources (gathered from the schema).
• Top nav to include relevant actions eg. "create"
• Expand list component to include actions eg. "edit" and "delete"

redbeard supplies faker properties for all fields in /schema and currently we don't need that when dynamically generating form inputs from the schema.

But perhaps we could use the faker property for inputs to then add a small "random" icon or similar for the input so you can quickly fill the fields with something relevant (other than "asdf" which I do all the time..) that will pass any validation correctly. I see this especially being useful for UUIDs, and any other fields that have a pattern property.

Originally there were duplicated methods around town doing various incarnations of traversal up and down the schema to retrieve things. This has all been moved to /lib/transformers/schema and is now tight and tested.

We should scour the codebase to remove any traces and replace it with methods from the transformer eg. mapSchemToData, mapSchemaToFormInputs.. or update/create new methods where appropriate.

React usually warns when dud prop type values are being passed, though nothing seems to be spitting to the console.

I feel like JSC was a good alternative to JSHint a year or two ago. But those days I think most projects standardized on a babel + eslint stack.

they kind of both do the same thing, but you're trying to standardize the stack so I think it would be only fitting to use it in here as well. even for the sheer least surprise factor

Make RBA work with the new envelope formats in RB API

Currently native fetch is used, but as mentioned in #36 it's not supported that much just yet. Possibly replace with axios ? It's pretty good, A+ promise compliant, and we've used it on a few projects now with no hassles. Unless there are compelling reasons to use another lib?

I think we should ignore all of /dist and leave that as purely a buildable folder that can be wiped/altered/rebuilt with no consequence. This feels cleaner.

This would mean we can move /dist/css and /dist/font into perhaps /src and use webpack (#6) to build relevant files from /src -> /dist.

It's usually always a nice idea to add this. Point in case, as soon as I ran npm i, it installed react 0.14.8 and it's listed as 0.14.3 in the package.json.