-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace jstree with jquery ui sortable #569
Conversation
86a767e
to
7681138
Compare
[insert pictures with explanation too, please. would be appreciated]. |
81b9475
to
822dd60
Compare
@Mandily @tvdeyen I'd love input on this page while I'm editing. The biggest concerns for me are around adding new taxons. On the old page you would right click a taxon and "Add" a new one as the new last child. That taxon would be called "New node" and your focus would be automatically set to edit that name in-page. My current implementation has only an "Add Taxon" button in the header. Clicking that button inserts a taxon called "New node" as the new last child of the root taxon. In order to rename any new taxons a user would have to "edit" that taxon by leaving the page. That was the easiest thing to implement, but I'd be happy to entertain alternative interactions. |
Thanks Kevin. jstree was terrible to use, flakey, and made us keep around a lot of cruft (custom json routes). I am very happy to see it go. |
Fun fact: I also have a branch for removing jstree, but hadn't a chance to work on it any further. I use the jquery nested sortable plugin. A new dependency, yes, but a very small one, though. The reason why I choosed this plugin was: nesting. Jquery sortable does not support nesting; only sorting elements on the same level. But we want to be able to move a node into another one, right? Regarding the context menu: I would remove it and add buttons besides each node to add a child node. We should also clean up the table columns. AwesomeNestedSet does not need a position column and nested sets in general work with parent, left and right columns. But the taxons table has all of them. Maybe I can free some time to publish my branch. Would love to here your feedback on this. |
end | ||
resources :taxons do | ||
member do | ||
get :jstree |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably drop this into an extension in case anyone has an iOS or Android app relying on these endpoints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😒
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just saying, removing from the API might really upset anyone who wants to upgrade, but they're using this in their iOS or Android app. I know my previous employer Kabuni is using it in their iOS app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more a fan of killing it, as it wasn't ever actually published in the public API on the old docs site:
https://guides.spreecommerce.com/api/taxonomies.html
We can make a note in the release notes pointing to the commit if they want to pull that code into their own stores. I would consider that a better upgrade path than supporting it as an extension.
Though not removing the routes and just axing the javascript is still a good improvement... Maybe we do leave it till we just deprecate the entirety of the API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Sinetheta yea if you can at least pull those commits that remove the ruby side out into a separate PR it would be nice.
Oh, but I'm sneaky @tvdeyen $('#taxonomy_tree ul').sortable
connectWith: '#taxonomy_tree ul' Bam! nested sortables. Pull it down. Play around a bit. I think it works pretty slick. |
Ha! You are great @Sinetheta |
I'd like to see the original 'move' icon used instead of the 'sortable' icon you've used here. A bit more space between the two icons would be nice too, so we can minimize the chance of the user missing their target and clicking on the wrong icon. Did you/can you remove that error message when the user tries to drag a row to the top level? It would be better if we could just not allow them to do that in the first place. Otherwise looks good! |
I tested it and find it very hard to drag a node into another one. It's so hard to hit the trigger, that I thought I am aware, that another dependency is not pleasant, but swapping out If you still want to go only with |
822dd60
to
51bcc2d
Compare
Thanks for taking a look at it @tvdeyen. Can you explain which drag operations were problematic. Personally I found it at least as functional as jsTree was (dragging any tree structure is going to require playing around until you get the hang of the particular implementation). One thing that was giving me a problem, was trying to get something into the bottom most position of any list (it always wanted to be a child, not a sibling of the element above it), so I tweaked some settings and I think it feels more intuitive now. I'd be happy to give nestedSortable a shot though if this still isn't feeling good enough. |
Feels much better now. Great work, Kevin! There are still smaller UI glitches, but the dragging is perfect. Great to see that we don't need any additional plugin for that feature. Regarding the routes: Deprecate and then remove with the next release. |
We're going to rebuild the taxonomy views with jquery UI
51bcc2d
to
0a093fb
Compare
I've added the api routes back in @BenMorganIO @cbrunsdon, we can just rip them out when we address the API as a whole. I think we're good here, unless anyone has code related feedback, or UI/UX suggestions. |
It can be tricky to drag a sortable to the final position of a list. Because of the placeholder empty lists we have placed there, it always wants to jump *into* the last item and become a child. `.ui-sortable-over` is applied to all of the ancestor lists of the placeholder to give a "lower edge" target (padding-bottom) and make it easier to sort to the last sibling position.
This guy is jsut kinda floating here, not doing much of anything. We can see that it's a tree.
0a093fb
to
8a6ffc0
Compare
👍 |
Yea, I'm good on this one too, thanks @Sinetheta |
👍 |
Replace jstree with jquery ui sortable
This key was used by solidusio#569, but the translation key was missed.
I just noticed that when creating new taxons, they don't get the right parent_id, but taxonomy_id (it worked for me only for first taxonomies of sample data whose ids are the same). I changed the js files that taxonomy_id is not really needed, otherwise I find it must work if we force to assign the parent_id in the api by removing the unless statement. |
We are not using JSTree anymore (solidusio#569) but we still have these routes available for stores that used it outside JSTree scopes. We decided to deprecate these routes long time ago but we never did it. See also #194. Once we've deprecated this enough we can probably just resurrect solidusio#664.
We were using jsTree in this one place only, to draw a taxonomy tree and let people drag around taxon leafs. Since we already have jQuery UI sortable, I thought that we could eliminate a dependency.
Changes
/api/taxonomies/2?set=nested
to render the entire tree.Before
After