Rewrite the Admin UI in React #503

Closed
JedWatson opened this Issue Jul 30, 2014 · 75 comments

Comments

Projects
None yet
@JedWatson
Member

JedWatson commented Jul 30, 2014

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!

@webteckie

This comment has been minimized.

Show comment
Hide comment
@webteckie

webteckie Jul 30, 2014

Contributor

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 :-)

Contributor

webteckie commented Jul 30, 2014

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 :-)

@robashton

This comment has been minimized.

Show comment
Hide comment
@robashton

robashton Jul 31, 2014

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 :-) ) 👍

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 :-) ) 👍

@metasansana

This comment has been minimized.

Show comment
Hide comment
@metasansana

metasansana Jul 31, 2014

Contributor

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.

Contributor

metasansana commented Jul 31, 2014

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.

@ayoungh

This comment has been minimized.

Show comment
Hide comment
@ayoungh

ayoungh Jul 31, 2014

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?

ayoungh commented Jul 31, 2014

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?

@tim-smart

This comment has been minimized.

Show comment
Hide comment
@tim-smart

tim-smart Jul 31, 2014

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

Very similar to React in some regards

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

Very similar to React in some regards

@SharadKumar

This comment has been minimized.

Show comment
Hide comment
@SharadKumar

SharadKumar Aug 1, 2014

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

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

@JohnnyEstilles

This comment has been minimized.

Show comment
Hide comment
@JohnnyEstilles

JohnnyEstilles Aug 1, 2014

Member

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?

Member

JohnnyEstilles commented Aug 1, 2014

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?

@SharadKumar

This comment has been minimized.

Show comment
Hide comment
@SharadKumar

SharadKumar Aug 1, 2014

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.

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.

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 1, 2014

Member

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 ;-)

Member

JedWatson commented Aug 1, 2014

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 ;-)

@ryanflorence

This comment has been minimized.

Show comment
Hide comment
@ryanflorence

ryanflorence Aug 1, 2014

<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>

<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>

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 1, 2014

Member

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.

Member

JedWatson commented Aug 1, 2014

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.

@webteckie

This comment has been minimized.

Show comment
Hide comment
@webteckie

webteckie Aug 1, 2014

Contributor

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

Contributor

webteckie commented Aug 1, 2014

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

@ryanflorence

This comment has been minimized.

Show comment
Hide comment
@ryanflorence

ryanflorence Aug 1, 2014

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 :)

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 :)

@grabbou

This comment has been minimized.

Show comment
Hide comment
@grabbou

grabbou Aug 2, 2014

Member

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

Member

grabbou commented Aug 2, 2014

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

@JohnnyEstilles

This comment has been minimized.

Show comment
Hide comment
@JohnnyEstilles

JohnnyEstilles Aug 5, 2014

Member

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

Member

JohnnyEstilles commented Aug 5, 2014

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

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 5, 2014

Member

@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.

Member

JedWatson commented Aug 5, 2014

@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.

@JohnnyEstilles

This comment has been minimized.

Show comment
Hide comment
@JohnnyEstilles

JohnnyEstilles Aug 5, 2014

Member

@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.

Member

JohnnyEstilles commented Aug 5, 2014

@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.

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 5, 2014

Member

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

Member

JedWatson commented Aug 5, 2014

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

@grabbou

This comment has been minimized.

Show comment
Hide comment
@grabbou

grabbou Aug 10, 2014

Member

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.

Member

grabbou commented Aug 10, 2014

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.

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 10, 2014

Member

@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?

Member

JedWatson commented Aug 10, 2014

@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?

@grabbou

This comment has been minimized.

Show comment
Hide comment
@grabbou

grabbou Aug 10, 2014

Member

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.

Member

grabbou commented Aug 10, 2014

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.

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 10, 2014

Member

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.

Member

JedWatson commented Aug 10, 2014

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.

@mattcreager

This comment has been minimized.

Show comment
Hide comment
@mattcreager

mattcreager Aug 19, 2014

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?

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?

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 20, 2014

Member

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.

Member

JedWatson commented Aug 20, 2014

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.

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 20, 2014

Member

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.

Member

JedWatson commented Aug 20, 2014

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.

@mattcreager

This comment has been minimized.

Show comment
Hide comment
@mattcreager

mattcreager Aug 20, 2014

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

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

@mgan59

This comment has been minimized.

Show comment
Hide comment
@mgan59

mgan59 Oct 23, 2014

Contributor

@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?

Contributor

mgan59 commented Oct 23, 2014

@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?

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Oct 25, 2014

Member

@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!

Member

JedWatson commented Oct 25, 2014

@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!

@matogertel

This comment has been minimized.

Show comment
Hide comment
@matogertel

matogertel Dec 16, 2014

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!

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!

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Feb 15, 2015

Member

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

Member

JedWatson commented Feb 15, 2015

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

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Feb 16, 2015

Member

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)

Member

JedWatson commented Feb 16, 2015

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)

@dandigangi

This comment has been minimized.

Show comment
Hide comment
@dandigangi

dandigangi Apr 27, 2015

Is there an update on where this rewrite stands?

Is there an update on where this rewrite stands?

@eshiferax

This comment has been minimized.

Show comment
Hide comment
@eshiferax

eshiferax May 19, 2015

^yeah, also wondering myself

^yeah, also wondering myself

@BerkeleyTrue

This comment has been minimized.

Show comment
Hide comment
@BerkeleyTrue

BerkeleyTrue May 19, 2015

Contributor

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

Contributor

BerkeleyTrue commented May 19, 2015

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

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson May 20, 2015

Member

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.

Member

JedWatson commented May 20, 2015

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.

@JedWatson JedWatson modified the milestones: 0.4.0, 0.3.x May 20, 2015

@BerkeleyTrue

This comment has been minimized.

Show comment
Hide comment
@BerkeleyTrue

BerkeleyTrue May 20, 2015

Contributor

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 ;)

Contributor

BerkeleyTrue commented May 20, 2015

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 ;)

@kfancy

This comment has been minimized.

Show comment
Hide comment
@kfancy

kfancy Jun 18, 2015

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.

kfancy commented Jun 18, 2015

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.

@cameronroe

This comment has been minimized.

Show comment
Hide comment
@cameronroe

cameronroe Jun 18, 2015

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

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

@morenoh149

This comment has been minimized.

Show comment
Hide comment
@morenoh149

morenoh149 Jun 18, 2015

Member

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

Member

morenoh149 commented Jun 18, 2015

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

@kfancy

This comment has been minimized.

Show comment
Hide comment
@kfancy

kfancy Jun 18, 2015

@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.

kfancy commented Jun 18, 2015

@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.

@kfancy

This comment has been minimized.

Show comment
Hide comment
@kfancy

kfancy Jun 18, 2015

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

kfancy commented Jun 18, 2015

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

@SOSANA

This comment has been minimized.

Show comment
Hide comment
@SOSANA

SOSANA Jun 19, 2015

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

SOSANA commented Jun 19, 2015

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

@cameronroe

This comment has been minimized.

Show comment
Hide comment
@cameronroe

cameronroe Jun 21, 2015

@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.

@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.

@BerkeleyTrue

This comment has been minimized.

Show comment
Hide comment
@BerkeleyTrue

BerkeleyTrue Jun 21, 2015

Contributor

@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.

Contributor

BerkeleyTrue commented Jun 21, 2015

@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.

@grabbou

This comment has been minimized.

Show comment
Hide comment
@grabbou

grabbou Jul 16, 2015

Member

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.

Member

grabbou commented Jul 16, 2015

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.

@BerkeleyTrue

This comment has been minimized.

Show comment
Hide comment
@BerkeleyTrue

BerkeleyTrue Jul 16, 2015

Contributor

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

Contributor

BerkeleyTrue commented Jul 16, 2015

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

@grabbou

This comment has been minimized.

Show comment
Hide comment
@grabbou

grabbou Jul 17, 2015

Member

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.

Member

grabbou commented Jul 17, 2015

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.

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Jul 17, 2015

Member

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").

Member

JedWatson commented Jul 17, 2015

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").

@lennerd

This comment has been minimized.

Show comment
Hide comment
@lennerd

lennerd Jul 23, 2015

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?

lennerd commented Jul 23, 2015

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?

@niallobrien

This comment has been minimized.

Show comment
Hide comment
@niallobrien

niallobrien Aug 14, 2015

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

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

@kfancy

This comment has been minimized.

Show comment
Hide comment
@kfancy

kfancy Aug 14, 2015

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)
.

kfancy commented Aug 14, 2015

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)
.

@niallobrien

This comment has been minimized.

Show comment
Hide comment
@niallobrien

niallobrien Aug 15, 2015

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.

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.

@JedWatson

This comment has been minimized.

Show comment
Hide comment
@JedWatson

JedWatson Aug 15, 2015

Member

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.

Member

JedWatson commented Aug 15, 2015

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.

@dandigangi

This comment has been minimized.

Show comment
Hide comment
@dandigangi

dandigangi Aug 16, 2015

+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.

+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.

@dandigangi

This comment has been minimized.

Show comment
Hide comment
@dandigangi

dandigangi Aug 16, 2015

Suggest Reflux* sorry can't edit from mobile.

Suggest Reflux* sorry can't edit from mobile.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 18, 2015

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.

gaearon commented Aug 18, 2015

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.

@cameronroe

This comment has been minimized.

Show comment
Hide comment
@cameronroe

cameronroe Sep 1, 2015

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

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

@swagata-kundu

This comment has been minimized.

Show comment
Hide comment
@swagata-kundu

swagata-kundu Jan 13, 2016

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-

mudaimg

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

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-

mudaimg

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

@creynders

This comment has been minimized.

Show comment
Hide comment
@creynders

creynders Apr 29, 2016

Contributor

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

Contributor

creynders commented Apr 29, 2016

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

@creynders creynders closed this Apr 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment