Muuri: Opinions wanted on the API

Created on 2 May 2018  路  21Comments  路  Source: haltu/muuri

Hey everyone, I hope you're enjoying Muuri so far!

I'm currently refactoring Muuri's core to make it faster and easier on the memory. While at it I've been reviewing a lot of the internal functionality and thought a lot about the current API. There are some things I'd like to change, but before going deeper into that I would appreciate any feedback on the current state of API. What are the good parts and what are the bad parts? Is there something that won't be missed if removed etc?

help wanted question

All 21 comments

I tried out muuri in a few prototypes and I think its pretty cool. Kudos on your work.

I think it would be nice to add the ability to center the grid content in addition to align right in the layout options. In particular I want the margins on the grid to be even on each side since I am using it in a portrait style layout.

@Virtual-Machine thanks for the feedback! This isn't the first time that's requested, so maybe I'll look into that ;) My gut says this kind of feature should be handled via a custom layout instead of baking it into the core, but let's see.

Yeah in both my prototypes I ended up adding the feature in myself due to the client's request.

It would make the library a little more batteries included, but people could still override with a custom layout if they wanted to go further or have more control. It could even be offered as a suggested plugin in you want to keep the core extremely light.

Would love to have an option to drag outside the viewport.

Thanks for all the work!

@douwevdijk dragging outside the viewport? Hmm.. do you mean this: https://github.com/haltu/muuri/issues/9?

@niklasramo yes, the one thing to make it perfect :)

@douwevdijk Indeed. That's been way too long in the todo list. I'll do my best to land that feature asap ;)

@niklasramo first of all thanks for this great library. I am currently using muuri in a webapp that have a kpi layout/dashboard, like kibana. For my use case I need a dynamic switch from not draggable muuri to a draggable one. I have seen some limitations with the current api, I cant change the dragEnabled flag once the grid is rendered. One solution is destroy the element node of the grid and draw it again with the selected drag option. But I am wondering if this functionality could be integrated natively in the api.

@jagipas Yep, dynamic options have crossed my mind, but they're quite a pain to set up. As for your problem with toggling dragging off and on, that is totally doable with the current API. Check out the dragStartPredicate option. Here's an example: https://codepen.io/niklasramo/pen/LOzZPo

Hi;

I also like Muri pretty much. I would really enjoy if there would be "anchoring option" per container inlcuded. I think it could be in any application the case that a certain container should be anchored at a certain position, which is why, there are good reasons to inlcude it in the library.

Besides can you recommend me a way how the anchoring could be customly included?

Thank you in advance. =)

@MartinKrmer Muuri does not position the container elements, so you can position them as you wish with CSS.

However, if you have nested Muuri instances and a grid container is simultaneously a grid container and another grid's item then Muuri _does_ position the container, like all the other items. In this case you need to build your own layout algorithm that allows having fixed (anchored) items in the layout. Here's an example on how to build a custom layout algorithm: https://codepen.io/niklasramo/pen/LLbLLd

Allowing fixed elements in the grid is something that might be added to the core at some point (been thinking about it a bit too), but probably not anytime soon. If you'd like to see it sooner in the core I suggest opening a dedicated ticket for it and trying to figure out there _how_ it should be implemented (if at all) and then creating the PR for it.

This isn't particularly helpful feedback, but I think the API is already excellent. It's very clear, stable, and semantic. I'm a huge fan

I have one request. Please add a method to update the settings on existing Grid instance.

I want to update for example the layout, now I have to explicitly set the private property:
grid._settings.layout = layout

@dev-zetta yep, that has crossed my mind, but it's very tricky. Some options can be mutated on the fly, but others can't. Been waiting to face a real-world issue before implementing.

Yep, dynamic options have crossed my mind, but they're quite a pain to set up. As for your problem with toggling dragging off and on, that is totally doable with the current API. Check out the dragStartPredicate option. Here's an example: https://codepen.io/niklasramo/pen/LOzZPo

@niklasramo hihi, you mention about the toggling dragging off and on, I've tried using that API with Muuri.defaultOptions.dragEnabled = true / false but it doesn't seems to work.

It would be nice to have the following:

1) an event that is fired BEFORE a dragged item causes a move (right now in on('move') we're already in the middle of it.

2) a possibility to get the targeted item/indesl before a move/swap is happening

My use case is: I have to swap exactly 2 items in the grid with kind of a "preview" functionality. I have to revert the grid back to it's starting layout if I keep dragging the item over another target. Right now I have invested about 20 hours of my spare time trying to figure out on how to undo move history without having nasty side effects or endless loops when I move the item into the next one.

@bernhardberger Hmmm 馃 I don't think an event before the move event would be _that_ useful since there's only one operation really that's happening there, which is sorting the the grid items. And since the move event provides the details (which item moved, where it moved from and where it moved to) you can pretty easily revert the operation if you wish. What exactly would you like to do within that "beforeMove" event?

I would need to reset the grid to the sorting before the drag started (I'd need to do that before every single swap event). But imho that needs to happen before the last/current move event happens.

Right now I only get the history where the dragged item was being moved to. But I need to reset every move/swap OTHER than the item being dragged before the current move happens. (as I said earlier I need to swap exactly 2 items while leaving the rest of the grid intact - while maintaining a "live preview" of what would happen if I'd release the dragged item right now.

Unfortunately I absolutely need that functionality - however stupid that sounds because I'm in need to swap out the grid engine (mostly because Muuri grid is just an absolutely brilliant piece of grid layout!) without having to deal with different behaviour to the current solution.

If that reset happens after the current item is 'moved' I'm getting weird behavior. Maybe I've missed an obvious and easy solution, but I can't see through it..

I'm still struggling a bit to understand what you are trying to accomplish (maybe a small live demo would help?), but as I said it's pretty trivial to hook into the "beforeMove" logic within the "move" event.

grid.on('move', function (data) {
var items = grid._items;

// Revert the move/swap.
if (data.action === 'swap') {
    items[data.toIndex] = items[data.fromIndex];
    items[data.fromIndex] = data.item;
} else {
  items.splice(data.fromIndex, 0, items.splice(data.toIndex, 1)[0]);
}

// Do here what you would want to do in "beforeMove" event.

// Redo the move/swap (if you want).
if (data.action === 'swap') {
    items[data.fromIndex] = items[data.toIndex];
    items[data.toIndex] = data.item;
} else {
  items.splice(data.toIndex, 0, items.splice(data.fromIndex, 1)[0]);
}

// Do here what you would do in the "move" event.
});

Never thought about reverting the move like that! My solution was to use grid.move() which kind of sent me down the famous 馃悋 hole.

It's kind of hard for me to do a live demo if the current solution as it's some proprietary stuff / technical debt that I'd like to get rid of before it kills my sanity.. :D

I will however update my codesandbox sample and post it here when/of I get the desired behaviour working with Muuri. If I can't I'll do a real-life demo using Post-It's ;-)

@bernhardberger Yep, It's not that intuitive reverting and we are manipulating the internal _items array there which is always a bit iffy (but necessary here since we do not want to use any methods that would emit events and potentially throw us into an infinite loop). However, those swapping and moving operations are pretty much just copy pasted from Muuri's source, so they should be pretty safe to use :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

discobanco picture discobanco  路  5Comments

Sashkan picture Sashkan  路  3Comments

dedurus picture dedurus  路  4Comments

niklasramo picture niklasramo  路  7Comments

msdobrescu picture msdobrescu  路  5Comments