search

mkobuolys / flutter_deck

A lightweight, customizable, and easy-to-use framework to create presentations in Flutter.
https://pub.dev/packages/flutter_deck
MIT License
171 stars 24 forks source link

refactor: Don't require routes if a user doesn't want them #108

Open matthew-carroll opened 1 week ago

matthew-carroll commented 1 week ago

I'm assembling a slide show and I seem to be forced to provide a route for every slide.

In my case, I don't plan to show or distribute this presentation via web, so all of these routes are superfluous, but require me to type a different value for each one. I can't leave it empty, and if I copy paste the same value, then I get a navigation error.

It should be possible to assemble a slideshow without providing route names, if route names aren't needed.

mkobuolys commented 3 days ago

I think it's kind of related to my answer in https://github.com/mkobuolys/flutter_deck/issues/105. I agree that the route could be optional or simply generated on the slide deck launch. For now, the best way to go is to use the flutter_deck_slide brick when creating slides since it will automatically generate a route based on the name of the slide.

matthew-carroll commented 1 day ago

The amount of typing I did was already excessive. Going to a code generator is definitely the wrong direction. As a user I don't want to add more tools and complexity. Code generation seems like a solution to a problem that didn't need to exist in the first place.

I think there's a design issue going on here. There's a concept of slide show primitives, which are small, composable tools that users can compose to create a custom slides how. Then there's the concept of a particular slide show theme - that's a collection of pre-designed slides - like what you select from the sidebar in Google Docs.

A theme imposes all sorts of things on you, because the point is for you to essentially use the theme as-is, with minor adjustments.

But primitives are meant to sit on the other end of the spectrum. Each primitive solves the smallest problem possible, so that they can support a great variety of results.

If you consider the general audience for slideshows, there's an infinite variety of slideshows that people will want to create. Some will fall within your pre-designed theme, but 99% of them won't.

As someone who just built a presentation with this package, I would strongly encourage you to clearly separate the areas of this package that constitute primitives from the areas that constitute a theme, or an overall framework.

Going back to routes as an example - I have never wanted or needed routes in any slideshow presentation I've ever created. So while you may want them, and some others may want them too, there are clearly many use-cases for which this is just noise. And I don't think it's a good answer to say "well, in that case, go use a code generator". I think the answer is "let's provide primitives that don't care about routes, and move routes into the theme/framework side".