Option to toggle component visibility about devo HOT 12 CLOSED

I am yet to go through the codebase, my skills with frontend are very limited, will get back to you once I have taken a look and evaluated what all I can possibly help with.

from devo.

I was thinking of this too, but I am not clear on how the experience with this should be. There was another request for changing the layout before, and if we have a ground for that we would be able to support this use-case as well with a single card or two-cards layouts, but at the time I couldn't see an elegant and easy way of doing it.

I agree that asking people to build their own extensions doesn't make sense at all. I think we should hit two birds with one stone and work on implementing the layout scheme which should allow us to implement this as well. If you have proposals about how to go with this, I am all ears.

from devo.

The first thing that came to my when considering a change in layout was https://github.com/STRML/react-grid-layout
It also has a vue port: https://github.com/jbaysolutions/vue-grid-layout
Basically have a default layout but let the user decide how he actually wants to arrange the different feeds.

Next thing to consider here would be the option to show and hide different feeds.
The simplest thing would be a drop down with checkboxes of available feeds. Then the user can choose which feeds he wants to see.

What do you think? 🤔

from devo.

I remember playing with the vue-grid-layout last year sometime, but I couldn't make it work with a small effort, so I decided to let it stay for that time. I think it is a good idea to do: we can have an edit mode which would allow you to drag and resize the cards which would allow you to build your own layout.

In fact, we can make it in such a way that you'd be changing the layout only with the cards, not with the platform, which means that you'd arrange the cards and change the number of cards you have, and once you have the layout, the platforms that are displayed on the card can simply be changed just like it is done today, no need for the edit mode there.

The things that need to be done are:

• Integrate this library to the project.
• Create an edit mode/page which allows the user to change the card layouts as well as the number of cards.
• Save this layout somewhere in the store and display the regular UI with respect to that layout.

One of the long-term goals I have for this project is to keep things as simple as possible to be able to make the project approachable and make it manageable for a JS rookie myself. I have limited experience with the JS ecosystem, and I would like to stay away from introducing many dependencies into the project. The same also goes for simplicity: I want to be able to wrap my mind easily around this project so that I am not afraid of changing it, updating it, and fixing it when the time comes. I am not against introducing libraries, but I'd rather have it justified to use such a dependency, and it would be something like "we cannot do that thing without this".

For example, another option there would be to give the same functionality via a dropdown of fixed layouts, I imagine there'd be a bunch of fixed layouts that'd simply cover many of the cases:

• single card
• two cards
• three cards like today
• three cards like today but mirrored, i.e. two cards on the left and one on the right
• four cards

These five layouts can actually solve the majority of the use-cases, can be displayed in the UI via a simple dropdown, and can be implemented without introducing any dependency. Why should we not go down that route?

Also, in order to understand the impact of the dependency, I have simply installed the Vue version of this package on Devo, just referred to it in the App.vue file without using it to have it included in the bundle, then I ran npm run build.

Before:

  File                          Size                   Gzipped

  dist/js/chunk-vendors.js      193.05 KiB             65.91 KiB
  dist/js/app.js                35.41 KiB              7.87 KiB
  dist/css/app.css              15.89 KiB              3.08 KiB
  dist/css/chunk-vendors.css    12.15 KiB              1.58 KiB

After:

  File                          Size                   Gzipped

  dist/js/chunk-vendors.js      401.31 KiB             120.75 KiB
  dist/js/app.js                35.49 KiB              7.91 KiB
  dist/css/app.css              15.89 KiB              3.08 KiB
  dist/css/chunk-vendors.css    12.15 KiB              1.58 KiB

As you can see, the vendor file size has more than doubled, jumping from 193KiB to 401KiB, and since we don't deal with the network overhead here, the relevant sizes are the Size columns, not the Gzipped ones. In my computer using Chrome it takes ~40ms to load the vendor file locally, and I can see the page jumping when I refresh, meaning that even a timespan as small as 40ms for 200KB of JS has enough overhead of fetching + interpreting the JS that it is visible for the end-user with a glitch on the page.

Personally, looking at these numbers, I don't see much of a value introducing that library as a dependency instead of the dropdown option. Of course, it'd be nicer to let people resize their cards as much as they want, but considering the dependency tradeoff, it might not be worth it. If you can find a way to introduce that without that dependency, or bring the usage of it down, or you can find an elegant way of doing it without introducing such a large dependency, I will be all ears. But so far, it doesn't seem to be that good of an option against the fixed layouts one.

Would you be interested in exploring a fixed-layout option?

from devo.

Okay I hadn't thought about the performance impacts of the library. Makes sense to not use it and go for a smoother UX with fixed layouts.

Below is a list of possible permutations of fixed layouts for upto 8 cards (shamelessly stolen from tradingview.com), obviously we don't need 8 cards just attaching it for inspiration.

The tasks to be done here would be:

1. Creating a dropdown with list of possible layouts.
2. Saving the state somewhere in local storage, the state being the current selected layout and what feed is displayed on each card of the layout.
3. Adding the new layouts.

Thoughts?

from devo.

That design seems perfect indeed, we just need a very similar set with the 5 layouts that I mentioned above, and we can go for a simple dropdown design. I agree with the tasks you are planning on, but I'd rather have smaller PRs in reverse order:

• The different layouts would be added to the codebase, but nothing would be shown, and we'd get the chance to decide on how to reuse layouts, display them, design them, etc..
• Then would come the dropdown + storing the dropdown result somewhere.
  • Along with this, we can enable the layouts in the same PR as well.

That way it'd be easier to review and iterate I believe.

Regarding where to show this option: I was thinking of storing them in the options page, but we can also go for adding a simple layout icon to the left of the night mode toggle that would display the dropdown in an upside down manner, and this might be simpler to implement. Do you have something else in mind?

from devo.

By the way, we might need to think about what icons to use for those layouts. The project is using FontAwesome, it'd be perfect if we can pick something from there, but I couldn't find good ones for this usecase by a quick look.

from devo.

imo adding an icon to the left of the night mode toggle is better.
This way the user can easily play around with different layouts to figure out what looks best.

With regards to icons for those layouts, I couldn't find icons for all the layouts that we have planned in FontAwesome.
The screenshot I posted above is just simple svgs maybe we can just do something similar.

The icon for a single card layout as seen above would be:

<svg width="400" height="110">
  <rect width="18" height="16" fill="none" stroke="currentColor" rx="2" transform="translate(.5 .5)"></rect>
</svg>

Two card layout:

<svg width="400" height="110">
<g fill="none" stroke="currentColor" transform="translate(.5 .5)"><rect width="22" height="20" rx="2"></rect><path d="M11 0v20"></path></g>
</svg>

from devo.

Cool, I agree with you on both the placement and the icons. In fact, if these can be built with some simple SVGs that's also fine, we don't have to use FontAwesome for that as long as we name them properly in the codebase.

Are you planning to work on any of these?

from devo.

I built the initial layouts using CSS grid, which turned out to be very simple and I think layouts are very simple and easy to understand at this point. Here's the PR if you'd like to review it: #51

from devo.

The last step of this functionality is here: #53

from devo.

The changes related to this feature have finally been released with v1.8.0, therefore I am closing this issue now.

from devo.