Support External CSS (Example)

[seanhess]

In #97 @benjamin-thomas tried to implement TodoMVC using their external stylesheet and found it confusing.

Create an example implementing TodoMVC using their stylesheet.

Refactor as necessary to make it not terrible

[benjamin-thomas]

Hi Sean!

I've been playing with your library over the week-end and I'd be happy to contribute an example if you think it'd be useful.

My working example is here: https://github.com/benjamin-thomas/7guis/tree/063a04d7c3bf00fe230b245a124454a3853d7fbe/haskell/hyperbole/app

Can you think of a better way to handle imports?

Regarding this question (from #97 (comment)), I'm thinking it'd be nice to have an alternative "global import", something like import Web.Hyperbole.Minimal, that would only put the bare essentials into scope. The golden path would be to import Web.Hyperbole, not import Web.Hyperbole.Minimal. How does that sound?

Also, if you're open to examples contributions, it'd be interested in contributing "7 GUI" examples, which I think is an interesting benchmark because it's simple enough not to be a time sink, but complex enough to demonstrate tricky interactions and workflows.

Although I've never used vuejs, I've noticed that their doc references the 7 GUI examples (and the traditional todomvc), here: https://vuejs.org/examples/#counter

So, it could be a good way to demonstrate what the library can do, and also to demonstrate useful patterns.

Either separately from the docs.hyperbole.live site, or integrated into it?

I'd expect some examples to require a little bit of javascript to work, which would be interest to show as well.

[seanhess]

It would be great to have your help!

My working example is here: https://github.com/benjamin-thomas/7guis/tree/063a04d7c3bf00fe230b245a124454a3853d7fbe/haskell/hyperbole/app

If you'd like to submit a PR for the TodoMVC external CSS example, can you do one that only changes the views, but reuses the existing Effect and HyperViews? I believe only the view functions need to change.

Regarding this question (from #97 (comment)), I'm thinking it'd be nice to have an alternative "global import", something like import Web.Hyperbole.Minimal, that would only put the bare essentials into scope. The golden path would be to import Web.Hyperbole, not import Web.Hyperbole.Minimal. How does that sound?

That could work. Alternatively, I could be convinced to flip it on its head and require users to import their own view library of choice. So, something like this?

import Web.Hyperbole
import Web.Hyperbole.View

Then it would be obvious that there are options:

import Web.Hyperbole
import Web.Hyperbole.View.Minimal

I suppose it depends on how often people will want to opt-out of web-view, but it's come up once before, and philosophically, I'm a fan of composition over big default groups. I DO want to encourage users to try out the atomic CSS approach.

Also, if you're open to examples contributions, it'd be interested in contributing "7 GUI" examples, which I think is an interesting benchmark because it's simple enough not to be a time sink, but complex enough to demonstrate tricky interactions and workflows.

Neat. I hadn't heard of 7 GUI. I read the site and agree those would be both a great source of examples and a benchmark of how complete our support is. I'd love to incorporate them into the existing examples site, but the menu is getting long enough we need to start adding some hierarchy. Go break a leg, I'll figure out how to integrate it into the examples site later.

Things to keep in mind

• Please keep PRs focused: don't implement multiple things in one go
• Please keep PRs unopinionated: If you want to refactor something let's talk about it first.
• These need to work against the upcoming version in main, not 0.4. Expect thrash, refactoring, etc.

Thanks!

[seanhess]

Are there examples of other projects that have figured out how to deal with imports in a way that makes it easy for users following a golden path but doesn't force it down their throats?

[seanhess]

I opened #101 to separate this thread from the imports issue. let's move all discussion of imports and easy opt-out of web-view there. Let's keep this focused on examples

[benjamin-thomas]

If you'd like to submit a PR for the TodoMVC external CSS example, can you do one that only changes the views, but reuses the existing Effect and HyperViews? I believe only the view functions need to change.

Sounds good to me! I'll keep you posted.

[seanhess]

With the new atomic-css release, External classes are now as simple as using cls

el ~ cls "some-external-class" . bold $ "hello"

[seanhess]

@benjamin-thomas are you still working on this?

[benjamin-thomas]

Hi @seanhess, yes I updated my fork this morning in order to look into hyperbole's latest changes.

I've also got stuff to finish/redo here: #102

Sorry, I've been slow at getting back to you.

[seanhess]

No worries, I'll keep them both open then! Thanks

[seanhess]

@benjamin-thomas Will you have time to get the external css example done by the end of next week? I'd like to release 0.5 soon.

Oh, one thing I forgot to mention, there is a cls styleable modifier for atomic-css, but for your example, we probably want to show how you don't have to import Web.Atomic.CSS at all. Web.Hyperbole exports the class_ attributable modifier for this:

import Web.Hyperbole
...

el @ class_ "container" $ do
  el @ class_ "item" . class_ "selected" $ "You can pass all classes in at once, or compose them, which is useful for conditionally applying them"

[benjamin-thomas]

@seanhess I'm looking at this this today.

Btw, going a bit off topic, I took a better look at atomic-css this week and I quite like it! I use elm-ui at work but I'm not a fan as I find it deviates too much from "normal browser behavior".

But atomic-css feels much more familiar and useful, we can build on the knowledge we already have (evolution vs revolution).

Being able to fully style a page only via a CSS sheet still feels important though.

Quick feedback after having quickly looked at this early this week:

• it'd be nice to not have row and col at all (in hyperview, maybe they belong to atomic-css?)
  • a mostly empty page still bring an "unexpected" col from a hyper call (I presume)
• it'd be nice to be able to opt out of the CSS reset (or opt-in?)
  • maybe provide a "rawDocument" as an alternative to basicDocument?

For instance, if I define this very simple page:

-- Running Hyperbole 0.4.4b (fc9647b commit on main)
main :: IO ()
main = H.run 3000 $ do
    H.liveApp (H.basicDocument "Counter") (H.runPage page)

page :: (Hyperbole :> es) => Eff es (Page '[Counter])
page = do
    pure $ H.hyper MkCounter (viewCount 0)

div :: View c () -> View c ()
div = H.tag "div"

viewCount :: Int -> View Counter ()
viewCount n = div $ do
    div $ do
        H.text . pack $ show n
    div $ do
        H.button (Inc n) "Add"

-- ... other code not included for clarity

I would not expect this HTML body

<body>
  <style type="text/css">
    .col { display:flex; flex-direction:column }
  </style>

<div class="col" id="MkCounter">
  <div>
    <div>0</div>
    <div>
      <button data-onclick="Inc 0">Add</button>
    </div>
  </div>
</div>
</body>

But this one:

<body>

<div id="MkCounter">
  <div>
    <div>0</div>
    <div>
      <button data-onclick="Inc 0">Add</button>
    </div>
  </div>
</div>

</body>

None of these should be blockers though, just pointing to possible further improvements

[seanhess]

it'd be nice to not have row and col at all (in hyperview, maybe they belong to atomic-css?)

• a mostly empty page still bring an "unexpected" col from a hyper call (I presume)

Hmm, I never revisited the decision to set the hyper view to a flex column in hyperUnsafe after switching to opt-in for atomic-css. I'm not sure what to do: flex box is happier if you use it all the way down, it might cause unexpected beahvior to jump to display: block randomly. We need to play with it and see if we can get rid of it safely

Do you also mean that you think row and col and space should be removed from Web.Hyperbole.View.Tag?

it'd be nice to be able to opt out of the CSS reset (or opt-in?)

• maybe provide a "rawDocument" as an alternative to basicDocument?

basicDocument is just a convenience function if you want to get up and running quickly. You're meant to implement your own little document template. See Example.App. (So it's already opt-in). Maybe it should be called "devDocument" or something, and we could also throw the live reloader in by default? Now that I think about it, we should probably expose that Data.String.Interpolate (i) QuasiQuoter to make it easier for people write document functions. Any thoughts?