Some Background

The KeystoneJS Admin UI was originally built as a 'simple' web app, based on old-school form generation, submission and rendering techniques combined with jQuery for client-side UI enhancements.

This decision has helped us develop reusable processing techniques that are easily applied to server-driven projects (from contact form processing on websites to complete applications and APIs).

It's also been limiting though, and ultimately we want the Admin UI to be a rich client-side app. Now that the server side patterns are mature, it's time to focus on that.

Because we've known for a while that the Admin UI will be rewritten, this has unfortunately blocked several enhancements we've been keen to build, and which have often been requested by our community, including a plugin architecture, custom field types, and richer Admin UI functionality.

Primarily, the block has been that if we open it up to customisation then change the whole architecture, it'll create a backwards compatibility nightmare for anyone who's invested in the old system. So this is now the next big thing, that will lead to other big things, and I'm really excited to be digging into it.

Why React?

I've spent a long time trying to decide the best fit for Keystone's Admin UI, and have assessed a lot of frameworks including Angular, Ember, Polymer, Backbone and more before settling on React.

Polymer was the favourite for a long time - because web components are the future, and play a very important role in our long term plans for Keystone - but unfortunately it's just not mature enough.

React, on the other hand, has excellent support, a robust routing solution, is very fast, and does a great job of providing many of the benefits web components will bring, today.

It also plays very nicely with Browserify, which combined with a grunt workflow, provides a great development environment, and makes sense for the way we expect to implement custom field types and extensions.

The Plan

We don't expect this to be a massive, disruptive rebuild - it doesn't need to be. The first step will be to selectively replace server-generated code with React components that still behave the way the current Admin UI does, with a form-submission / processing / rendering workflow.

Once that is done, many of the blocks around allowing extensible field types and Admin UI customisation will be removed.

The next step will be to transition fully to a react app that will run client-side against API endpoints. In the same way we made the UpdateHandler and other tools work in a way that dramatically improves productivity when developing server-side processing workflows, we'll use this transition to develop great client-side app workflows that are reusable in projects. Very little will be specific to the Admin UI itself.

For the field types (and forms, and list UI) our intention is to develop reusable components that can be dropped into Keystone projects and reused outside of the Admin UI, providing rich functionality regardless of whether the server or client is doing the processing.

Some things will certainly need a rich client interface, but server-side HTML generation and processing is still important on the web, and hopefully we can create a solution that facilitates the holy grail of sharing code between the client and the server without being locked into either.

Can you help?

There is still a lot to be worked out around the best way to manage application state, extensibility and component structure. There will also be quite a bit of work involved in transitioning all the current UI elements to React components.

If you have experience working with React and would be happy to help, please let us know!

Congratulations on the decision! But I'm curious, the React website thinks of react as the "V" in MVC. Thus, I guess React is more like Knockout and not really like Angular, Ember, etc. Weren't you attempting to tackle the whole client side infrastructure? I don't know anything about React but if it is indeed more like Knockout, keep in mind that some companies currently using Knockout find a lot of shortcomings with it and are moving towards full MVC frameworks like Angular, Ember, etc. Just making sure you don't get too far into React to then realize that what you really needed was a full client-side MVC stack :-)

Good choice of client-side (Browserify and React is my go-to stack at the moment and I've never felt the need to add an M or a C to that :-) ) 👍

Hmmm, can't say I'm not disappointed. I've been experimenting with angular for a while now and it really is powerful. The learning curve is steep, but it's worth it once you get over that. For one thing you don't ever have to load jquery or even use it directly. Not to mention http requests are easier to manage with promises.

Guess I'll go read up on react then.

This sounds great but slightly puts me off development using keystone at the moment, what would you suggest in terms of starting a development with Keystone now or waiting till after these changes are made?

There is also Ractive! http://www.ractivejs.org/

Very similar to React in some regards

There are always lot of considerations, and I am hoping Jed is right. I have recently embraced Keystone and absolutely love it for its speed to realise outcomes quickly on a project. Future of Admin UI is key. I would have picked Angular with Keystone REST api. This decision has further evoked my interest in React though.

Market adoption and interest trends is also one of the vector to decide. I just ran a comparison of search trends in Backbone, Ember, Knockout, React, and Angular.
https://www.google.com.au/trends/explore#q=angularjs%2C%20reactjs%2C%20knockoutjs%2C%20emberjs%2C%20backbonejs&date=1%2F2011%2044m&cmpt=q

Like others on the thread, I'm also an advocate of Angular. However, after reading up on and creating my first app using React I can understand the appeal of selecting it over Angular, Ember, etc. I particularly like the server-side generation capabilities which can considerably improve the performance of rendering of initial state of a page. On the client side, React is smart enough to recognize that the components for the current state have already been generated (in this case by the server) and does not need to make any updates to the DOM. This feature is particularly beneficial from an SEO standpoint. While SEO is probably not a concern for the Keystone Admin UI itself, it may definitely be for our Keystone powered sites (if we choose the use React), especially when Keystone component become reusable outside the UI. I'm definitely looking forward to using react in one of my next projects.

I do have a question. Is the intent also to implement Flux along with React, in order to manage data stores and enforce a unidirectional data flow?

I like the point you make Johnny!
SEO has been one of my main concern areas for Angular, even though there are "hacks". Again, this definitely catching my attention now, to look into React and that client/server switch. If that works, then I can totally relate to the benefits that can be realised in component approach with web-facing forms et al dependent on lists and fields.

Looking forward to it all.

Thanks for the feedback guys!

A few clarifications from my research into React (and the other frameworks)...

@webteckie I think it's going to be OK. React powers the whole Instagram site and web app, an increasing amount of Facebook, and more.

As @JohnnyEstilles noted they've also just released flux which provides excellent patterns for architecture, and we'll either use this or something like it to manage the data stores and unidirectional data flow.

@metasansana sorry to disappoint you, but hopefully you like where we go with this. React is also very powerful, although it tries to do less than Angular. For me that's a plus: where Angular defines your whole front-end architecture, React feels more modular, the way I want Keystone to be. We don't need jQuery with React either, and I expect we'll use superagent for http requests - which is nice because it works in both node and the browser.

Not that this isn't also true of Angular / Ember / etc, but I've been really impressed by the quality of React; from the thinking behind it, to the maturity, to the documentation, guides and examples. It's been a pleasure to work with, the team behind it have done an excellent job, and Facebook and Instagram seem totally dedicated to its success. Big shout out also to @petehunt, @mjackson and @rpflorence whose work helped me get into React, and figure out how to make this shift.

@ayoungh please don't be put off - this won't introduce any breaking changes, the Admin UI will simply get better over time. We're starting off by just replacing what's currently rendered server-side with jade templates (and augmented by jQuery plugins), to being rendered client-side with React. Then we'll gradually replace more UI until we can finally move to a complete client-side app. The ability to transition gradually like this - as well as being able to start re-using Admin UI components outside the Admin UI without enforcing an entire client-side app framework on projects - was a big plus for React when making the decision.

As @SharadKumar says, I love Keystone for its speed to realise outcomes quickly on a project - this is all about doing more of that, and doing it better.

Now I'd better get back to coding ;-)

<drive-by-react-marketing>

For anybody bummed about not picking angular, this is from their last weekly meeting notes:

Key points:
scope hierarchy is a huge pile of shared state that many components from the application
because of two way data-binding it's not clear what how the data flows because it can flow in all directions (including from child components to parents) - this makes it hard to understand the app and understand of impact of model changes in one part of the app on another (seemingly unrelated) part of it.

demo
single data flow direction - always from the top to bottom
each state has an owner - some component - and only that component can change the state

https://docs.google.com/document/d/150lerb1LmNLuau_a_EznPV1I1UHMTbEl61t4hZ7ZpS0/edit

In other words, changing $scope is a lot like changing a css selector. Its virtually impossible to identify what cascading effects that has on your app.

Its not just angular, Ember is also looking to learn from React to sort out similar problems.

Many people with experience in production apps that implement 2-way binding (read: ember/angular) are finding incidental complexity and performance problems that React has wonderful answers to.

Anecdotal, but I haven't met a person yet who built something in React and walked away without wanting to do everything else in React :P

</drive-by-react-marketing>

Haha, thanks @rpflorence.

I've never been totally comfortable with how you control state flow with two way binding; I gave react 5 minutes and it won me over with its approach to this.

You've got my support! Let's do it! More stuff I have to cram into my little brains now :-)

More stuff I have to cram into my little brains now

Fortunately, a lot of react feels like going back to server-rendering where you just kick out html based on some data, so not too much to add to your brain :)

Cool, very good choice for Keystone @JedWatson , you can count me in! #ReactJS.

@JedWatson, are we holding off on new features until are the UI admin rewrite?

@JohnnyEstilles not specifically; depends on the feature. Updating relationship field UI is probably out; things like #510 shouldn't be blocked (or really affected).

My general / current plan is to keep enhancements & fixes going as much as possible in parallel, although I'll personally be largely focused on the migration to React.

I'm currently setting up React in a branch, but as soon as it's stable and non-disruptive I'm planning to marge it back into master so we don't have too much code divergence. Some things (like the updates I made to the gulp tasks earlier) have already been merged back in.

Also as soon as I've got the groundwork done in the branch, there will be a fair bit of work to migrate the field types to React components, so if anyone would like to opt-in to help with that it'd be welcome.

I expect we'll bump to 0.3.0 when the react fields are ready and go live. I don't really expect to need to maintain 0.2.x after that, but if we needed to, we could.

@JedWatson, thank you for the update. I'm in the process right now of converting one of my customers' apps to React myself. Once I'm done I'm be happy to pitch in.

@JohnnyEstilles awesome, thanks. Let me know when you're ready :)

Just wanted to ask @JedWatson whether I can write my own additional field? It's going to be related with Images! (Probably after I roll it out, we will be able to delete Cloudinary plugin). As I am working on that now in my project, I think that I can do PR at the same time.

@grabbou You'll definitely be able to. One of the major outcomes of the move to React will be the ability to include custom field types.

I've nearly got a basic build with React (+gulp + browserify) working in my react branch. When I do the next push, I'll let you know so you can have a look and give some feedback.

Your new field type sounds interesting, care to share more information about it? Refactoring the Image and File fields is a big thing we're looking to do soon too, so if you're working on the same thing, let's team up :)

Maybe open a new issue for it?

I will Jed, I will, as soon as I get home. It's going to be really amazing, you will like it, so we will stay in touch! :)

Probably that type of field will be merged with Keystone as it's a core one (I hope you will find it to be like that), but I quite like the fact that I will be able to write plugin field soon. Then, we will be able to separate fields from core and maintain them separately.

OK the first (seriously rough) implementation of rendering forms using React is in, anyone interested is welcome to have a look in the react branch.

My initial goal was to get the Item Details screen bootstrapping itself with React components for the form elements, just with a basic Text field. This lets us start building out the UI for the current field types, when that's ready we'll see what to do with the overall app structure.

It renders the field correctly, including a field note, the form element can be submitted, and updates are rendered from the server successfully.

I'm using a simple test list to work against, will keep adding field types as I work on them:

var keystone = require('keystone');

var Test = new keystone.List('Test', {
    autocreate: true
});

Test.add({
    str: { type: String, note: 'A field note.' }
});

Test.register();

I've also got gulp and browserify to play nicely, I'm quite happy with the watchify implementation (although the final process will probably be completely different, I think it will dynamically build itself on keystone init with just the fields that are actually defined in lists).

The build folder is excluded from git, so before you run your app, do this in your keystone project folder:

gulp build-scripts or gulp watch-scripts.

Love the decision to run with React / Flux, I've been using this approach extensively... It's not always easy, but the outcome always feels 'reliable'.

I'd love to help, where's the best place to get started?

Hi @mattcreager, great to have you on board!

The basic framework is in, and we're currently transitioning the field types one at a time, I've done string, boolean, email and location as examples of how to get fields of varying complexity rebuilt in React.

I'm working on the select-type fields next (select, relationship) but would welcome input on the best way to do it (I'm a fan of selectize but not sure the best way to integrate it into React, and I'm not keen on bringing the jQuery dependency forward into our new stuff (although it may end up being required for things like the Markdown editor).

@JohnnyEstilles has opted in for the date and diatetime fields, feel free to pick any of the other ones and let us know, then migrate it across.

You're also welcome to join our Slack if you like, some discussion and planning is happening in there, let me know and I'll shoot you an invite.

Some more info on how to get into the React build:

I added the location field in a single commit, if you check it out you'll see the process to follow when adding support for a new React field type: 8ab2568

There's a brief convo there between myself and @grabbou there too which may be of interest.

I'll document the React Field API and creator soon, probably best to quickly build a few more field types first though as the concepts on how best to make it work are evolving pretty quickly as we add more types.

Awesome @JedWatson thanks, please hit me with a Slack invite :)

@JedWatson Wasn't sure best place to post feedback/thoughts on React. I pulled your branch last night and looked at the code. Looks like a great start to the form display. Curious going forward if there have been discussions on any of the Flux workflow tooling. I've been learning React and have started with Fluxxor there are others of course such as Reflux. I don't have a preference at this point as I'm only prototyping a side project with React, but I'd like to get involved in the React work for keystone. Are there conversations on Slack I should join? Or going forward should we just open up a compare/pr for the react branch and have people post their comments there that way everything is on github?

@mgan59 no discussions about Flux yet; the build process is working well though, and I've been doing a lot of R&D / learning in other small projects too which will make their way back into Keystone soon (especially the new react-select component).

Would certainly love some help, the best thing is to pick up a field type and convert it. Once they're all working in React, we can make a beta release, and start on the more significant (but technically more trivial) overhaul work.

If you'd like to chat about anything there's a dev-react channel in Slack and I've just sent you an invite... other than that though, you're welcome to just start hacking and make PRs on the react branch!

Hi Jed, just pulled the React branch and pointed the blog sample app to it, but I get 'App not defined' in App.Views.Item.renderForm. Any quick steps to get a sample React Keystone running ? We're really looking forward to see how this will turn up, as we're using Keystone for our customers more and more!

Sorry, forgot to build it! All good now :-)

See #782 for field types progress and to claim a type you're working on.

we are looking forward to see some progress coming out. Do I expecting any changes on the lib/list.js? because I am thinking about to make some static pages for creating options. thank you for the great work! @JedWatson

@jjhesk Ive created configurable site-wide settings by creating a settings model and disabling creation or deletion of it. Works well for the time being as you dont need to edit any core files, but it would be nice for the UI to better display a "settings" page.

@danielmahon are you saying you've come up with a way to, for example, enable/disable what the Admin UI shows based on the type of user? If yes, is that something that can be contributed? If not, @JedWatson where in the roadmap would this be? I think this is a fairly basic requirement for allowing users to the Admin UI but restrict what they see based on the user role.

@danielmahon its amazing.. I have been looking at the core file with my eyes crossed. Please send me the link of your git. I want to test it out!

@webteckie for the basic roadmap of the access-control level. We will have alot more to implement in between each line of code. For now we should be able to implement that on the model base level. The goal of this feature should be easy to extend and implement on all code base standard.

In my opinion, there is an array to control all the groups or called roles

1. administrator (must) and it is a json map out if each of the capability is enabled or not
   example:

{
'role': 'administrator',
  'caps': {
 'read':true,
 'write':true,
'approve':true
 }
}

1. basic user(must) - let the user to login but nothing can see yet because there is nothing set on the cap.

Capability
This is the array items to hold all the access rights. The developer can easily extend more capabilities to suit for their business needs.

if this is something we want to go then we need to start a new thread about this and put on 0.4.x roadmap. Also refers to #269, #334

@webteckie @jjhesk Currently Ive only tested this for user configurable fields, to set simple things, like a base site title and google ID for example. Im sure you could use the same idea to implement logic in your other models to change how the admin ui is displayed (disable field editing for example) but Im sure there are race conditions that would need to be looked at with other models being dependent of this one. All im doing is storing the settings once changed into keystone and then loading them into the local variables in middleware.js. Im sure there are better ways of doing it, but at least for this you dont need to change the core.

Again, this was just a quick concept for a site in development and not completely thought out.

https://gist.github.com/b1af14a3b3641c10b078

@jjhesk, @JedWatson had made a comment on #106 that he was currently implementing list restrictions in the Admin UI based on the type of user. Somehow I thought this was also what @danielmahon was talking about. But I'm mainly interested in what @JedWatson said he was doing in #106 and the status of that. It didn't come up in the recent community meet we had and thus I'm curious as to its status or where in the roadmap it belongs.

@danielmahon right, this may solve the problem in short run. I am sure for the next version it will come up with a well thought solution for modular settings for easy implementations. By then all the dependency will have big changes perhaps that all the data in the collection will need to remove and start over. I might want to wait for them to give us direction in structure first. @JedWatson

Awesome, I've been using React a lot lately. Would be happy to contribute to the migration. Is there a react branch somewhere?

I believe for the most part this is complete. Admin in 0.3.0 is completely in react. @JedWatson Should this issue be closed?

Great! Any plans to use React at other parts? Ot it is possible already?

13 февр. 2015, в 03:48, Berkeley Martinez notifications@github.com написал(а):

I believe for the most part this is complete. Admin in 0.3.0 is completely in react. @JedWatson https://github.com/JedWatson Should this issue be closed?

—
Reply to this email directly or view it on GitHub #503 (comment).

If you are asking about using Keystone with a react app, yes it is possible.

@aksonov just modify your keystone's express to use a ReactJS template/view engine.

closing 0.3.x uses react for the adminUI

There's still a lot to do. Will explain shortly.

We've rewritten the Admin UI Forms in React and migrated the field types. This was a pretty major undertaking as it involved a complete rewrite of the field UI components.

That's really a prerequisite task though. We're getting closer to having the Admin UI in React but there's a lot we can now do. The ultimate goal is to have made the Admin UI a SPA.

I'm going to open some more granular issues for these as I spec them, but generally the roadmap looks like this:

• Rebuild List Filters / Sorting and Header UI in React
• Rebuild List (table) in React w/ Column component per Field type
• Use API to load List view entirely client-side (probably our first implementation of react-router) and move the rest of the UI (sorting, deleting, pagination, etc) to React
• Rebuild the Home screen and Header / Navigation Chrome in React
• Expose API endpoints for entirely client-side interactions (create / update items, etc)
• Use API endpoints for Item actions (create / save, etc) instead of submitting POST events
• Bring the whole thing together using react-router into a single page app

While this is being done, we'll start being able to open some parts of the Admin UI up for customisation, but I'm still planning to be conservative with it until we're confident with an API we're happy to support long-term.

I also want to flag that a large portion of the background work here is getting all the field types under test - when we switch from POST to AJAX requests, I want to make sure that we have a way to ensure POSTing to all field types (e.g. for use via the UpdateHandler) continues to work as a first class use-case, even though it won't be used by the Admin UI anymore. @sebmck is generally leading this charge.

Once this roadmap is complete, it's going to be awesome. And then we can close this issue :)

In the meantime if anyone's interested in taking on part of this work it may not be obvious where or how to jump in, but there's lots we could use help with so reach out to me in our Slack (and if you're not in our Slack ping me, I'll add you)

Is there an update on where this rewrite stands?

^yeah, also wondering myself

The admin panel is written in react as of 0.3.0. This issue should be closed.

Stop trying to close this issue before it's done :P

The production release is still in the state I described above, with a mix of jade, server-side generation and React components.

Most of the items I listed above are mostly done, - if you're interested in seeing the progress, check out the elemental-integration branch. We've created another project, Elemental UI which we are using to develop the standard React form components for Keystone, which will also be available for use in projects outside the Admin UI.

I expect to release 0.4 within the next few weeks, having completed this transition.

IMHO It seems like that should really be a separate issue. Maybe something along the lines of 'elemental ui transition' Especially considering how much of a big deal the 0.3.0 release was. It also helps give a sense that the project is moving and not stalling on issues from years ago.

#AlwaysUseTwoSpaces ;)

Hi @JedWatson et al, I'm late to the party but very interested and confident to start up a couple of large-scale projects with Keystone... and am a big fan of ReactJS. Very happy that you guys made that decision over the two-way data binding approach of others.

Not exactly sure how I can contribute (where to start, really), but I'm happy to if there's still some need.

Any thoughts on using react-router for an isomorphic routing solution to keystone?

@kfancy there are issues labeled easy-for-beginners where we provide guidance

@cameronjroe I'm actively developing a couple of projects with react-router for exactly that behavior, I will be able to give some more in depth information on that topic soon but at minimum I'd say it's a solid package to work with.

Also, I'd recommend a pure flux implementation instead of using one of the myriad of "wrappers" (Fluxxor, etc) that sit on top of it. Flux is simply a philosophy at this point, and an easy one once you wrap your head around it... so far for me it plays well with ajax as well as websocket asynchronous communication.

@morenoh149 what about open issues or subprojects working with react components?

This would be epic. Love react.js. woooooooohooo!

@kfancy Yeah react-router would allow for route configuration of keystone isomorphically. Percolate has a nice example just using server.use from express to run the routes from react-router.

@JedWatson I would definitely wait for React Router 1.0.0 (currently in beta) release. It has a fantastic new api and a scalable async routes config api that would work great for Keystones admin panel.

Personally I think the admin UI should be moved into another package and required as a middleware. Would've simplified things a lot and also allowed further customisations w/o touching the core.

The admin panel is the CMS you can't have a CMS without it. If you remove it then keystone just becomes mongoose...

I would argue with that, take a look at Django project & Django admin, which is an opt-in and it's not required for the project to work. For example, I can easily bootstrap REST api and use admin panel for quick dev scaffolding.

Anyway, separating 'admin' to a different repo is just small improvement to make dev better (imo) - for end users it will be the same w/o any breaking changes or additional steps to take.

Separating the Admin UI from Keystone is part of a longer-term vision I've got for it to become more modular, at the moment it's not so simple as the field types are (unfortunately) quite tightly-coupled.

There's a lot of refactoring going around the API and express app that's probably going unnoticed that's preparing it for this.

We'll launch the React / Elemental version first because there will be quite a few breaking changes (to internals that I know are being used externally) but I expect this vision will be realised towards the end of the year.

As a brief overview:

Keystone is really several concepts that work together:

• Rich schema definition (currently implemented as a Mongoose functionality superset)
• Additional functionality (e.g UpdateHandler) on top of the Schemas
• Express app configuration (appropriate for most data-driven websites and apps)
• Admin UI generates from the Schemas

Basically the core is the schemas (i.e keystone.List) and the rich field types. My plan is to make them much more portable and separate the functionality from its current tight coupling in the rest of the system (and rebuilding the Admin UI in React is the biggest step towards this). Bringing some of the schema / field type functionality to the client-side will be a big advantage as well.

Eventually each module will be able to be separated into its own package, and keystone will continue to bring them all together for the common use case (based on the principle "make the 80% easy, the 20% possible").

I really would love to use Keystone for my next client project. Is there any chance to get an overview of your progress with this issue as it seems to block many other smaller issues (multi delete items in a list, sub collections, etc.)? Maybe some kind of roadmap issue I was missing while searching for something where the discussion takes place?

May I suggest using Reflux instead of Flux, simply to reduce the complexity and lower the barrier to entry? Thanks.

First I'd have to ask how it lowers the barrier to entry? Flux is not a
hard architecture to understand, and once you put a wrapper in the way,
you're stuck with their implementation of the flux architecture. Upgrades?
Maybe they don't keep up with them.

My personal opinion, vanilla JS is always better unless there's an explicit
reason to use Yet Another Library.

On Fri, Aug 14, 2015 at 2:16 AM, niallobrien notifications@github.com
wrote:

May I suggest using Reflux instead of Flux, simply to reduce the
complexity and lower the barrier to entry? Thanks.

—
Reply to this email directly or view it on GitHub
#503 (comment)
.

In my opinion, the whole notion of using a dispatcher is a little unnecessary, Reflux solves this. It's like comparing Angular's ngRoute with UI-Router: the 3rd-party offering is just far superior (UI-Router).
It would also reduce the amount of code required.

I am currently building it using a simple data management pattern implemented with my store-prototype module. I view Flux as more of a "concept" than a "framework" and usually implement whatever level of it I feel is appropriate in different projects.

Implementation in progress for the List view is here, if you want a preview: https://github.com/keystonejs/keystone/blob/elemental-integration/admin/src/stores/CurrentListStore.js

If we do go with a more complete Flux architecture down the track, I expect it would be redux by @gaearon, he's doing amazing work on it.

Feedback on the current approach and state of the implementation in the elemental-integration branch is, of course, welcome, and if anybody wants to step up and help me with it that would be great. Get in touch on the Slack and I'll help you work out where to get started.

+1 Jed

Flux is an architectural pattern. If you're going to suggest it, provide the technical gains, not that it is just easier to use.

Suggest Reflux* sorry can't edit from mobile.

May I suggest using Reflux instead of Flux, simply to reduce the complexity and lower the barrier to entry?

Be aware that Reflux gives up most benefits of Flux attempting to be less verbose.
This might give you some idea.

Hey Jed, just updated some of the API docs. Would love to join the Slack group!

Hi JedWatson,
I have following react_select items from drop-down as shown below plz let me know how can i make it draggable for ordering content blocks items-

Please suggest I am using keystonejs where it is using react for admin ui ,so I need to drag and put blocks item accordingly.

@mxstbr is Chuck Norris'ing this one at #2566