here's a Snowpack/TS/Crank/XState example

[geddski]

in case you wanted to show an example using this stack.

https://github.com/geddski/play-crank

[brainkim]

Looking good! I did the xstate calculator in Crank. It’s cool that logic can be reused and I’m curious to know how xstate and crank can work together.

[brainkim]

I’m also very curious to hear more about snowpack and if we can support it better. Maybe you have thoughts on bundling (#65)?

[cristianfalcone]

Nice!
I've been playing too with something that may end up like Next.js or Nuxt.js, but with Crank! I will try with Snowpack. (I love Crank btw)

https://github.com/cristianfalcone/pedal

[brucou]

Actually the calculator here is buggy. If the state machine was reused, then the machine itself is buggy. One bug I found:

type 999, then -, then +, then 3 and you get 996

[brainkim]

@brucou
https://codesandbox.io/s/github/Glutnix/xstate-vue-calculator/tree/master/?from-embed
Happens in the vue.js calculator too.

[brucou]

@brainkim that is what I suspected too. Which gives birth to two hypothesis: 1. writing state machines does not dispense from writing tests, 2. even when the machine is already given (already drawn in the Constructing Statecharts book), xstate complexity may lead to mistakes.

[brainkim]

@brucou I agree. I think the ability to reuse logic across frameworks is incredibly attractive but I’m still not 100% sure what the actual process of developing state machines looks or feels like.

https://twitter.com/FredKSchott/status/1257750204515643392
@geddski Snowpack 2.0 is looks really really attractive and I’m probably going to investigate it in the next couple days.

[brucou]

@brainkim I have been trying to figure out that process over the last four years, anytime I had a good use case. I have a version of the 'real world' application Conduit (it is a medium clone but less cute) implemented with the Kingly state machine library (I am the author :-). The machine is finished, implementation is done, but I found a simplification which should reduce its size and make the logic simpler. I still haven't been able to update the code accordingly, as I was busy developing the devtool and compiler (just finished that yesterday). When I am done with a implementation of Conduit, I may finally publish the 1.0, update the tutorials on the documentation site, and elaborate a set of good practices and pitfalls to avoid.

Anyways, the Conduit app is an interesing application to implement, I would recommend you to do that with Crank, even though I must say that it can be much more time-consuming than the TodoMVC. Or maybe it would not be so, because of the way you can directly use promises and render in Crank? Don't know. The app is not complex per its behavior, but there are many screens and actions to implement, which is why it is considered a real world app.

[brainkim]

I’ve been avoiding the RealWorld demo for now because I thought it required some sort of full-stack solution with routing and ssr, which we don’t have a clear story for yet and would require breaking some new ground. I’ve always found the hardest part of building apps to be the styling, so if there is a stylesheet we can just use for RealWorld I could probably get it done pretty quickly.

[brucou]

I haven't required any routing library to implement the routing, same goes for ssr. All is done on the client, and that is the case for the React/Vue solutions for what I remember. You can also do SSR but that is extra complication. RealWorld comes with a premade style sheet yes. You just include that in your html file. I haven't written a single line of CSS. Even the requests and so on you can take it verbatim from other implementations (the api is fixed) -- I took mine from the Conduit's hyperapp implementation. But it is still some work.

…

On 5/6/20, Brian Kim ***@***.***> wrote: I’ve been avoiding the RealWorld demo for now because I thought it required some sort of full-stack solution with routing and ssr, which we don’t have a clear story for yet and would require breaking some new ground. I’ve always found the hardest part of building apps to be the styling, so if there is a stylesheet we can just use for RealWorld I could probably get it done pretty quickly. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/bikeshaving/crank/issues/72#issuecomment-624776316

-- ---

[brucou]

here is the html that you can copy pretty much verbatim, except maybe for the bundled script part:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf8" />
    <meta name="viewport" content="width=device-width" />

    <title>Conduit</title>

    <link rel="icon" type="image/png" href="/favicon.png" />
    <link rel="stylesheet" href="/global.css" />
    <link rel="stylesheet" href="/bundle.css" />
    <link rel="stylesheet" href="//demo.productionready.io/main.css" />
    <link rel="stylesheet" href="//code.ionicframework.com/ionicons/2.0.1/css/ionicons.min.css" />
    <link
      href="//fonts.googleapis.com/css?family=Titillium+Web:700|Source+Serif+Pro:400,700|Merriweather+Sans:400,700|Source+Sans+Pro:400,300,600,700,300italic,400italic,600italic,700italic"
      rel="stylesheet"
      type="text/css"
    />

    <script defer src="/bundle.js"></script>
  </head>

  <body></body>
</html>

Here is the client-side router:

export default function apiRouterFactory(location, addEventListener) {
  const api = {
    subscribe(listener) {
      addEventListener(
        "hashchange",
        ({ newURL, oldURL }) => {
          const hash = api.getCurrentHash();
          listener({ newURL, oldURL, hash });
        },
        false
      );
    },
    getCurrentHash: () => ["", location.hash.replace(/^#\/?|\/$/g, "")].join("/"),
    redirect: newHash => history.pushState(null, null, document.location.pathname + "#" + newHash)
  };

  return api;
}

It is simply listening on the hashchange client from the browser and change the page you display according to that. No need for a complex or generic library here.

So your component may take a url parameter, and inside the component body you yield different stuff according to the pattern matched by the url. Hopefully, that should not be too much of a problem in a Crank context.

[geddski]

@brainkim whoa yeah it is! A built-in bundler for production... sick!

[ryhinchey]

Im going to start working on the real world conduit example today. I’ll start a discussion with a link to the repo. Looking through other examples like vue and react, we’re ready to build it with crank 😁

[brucou]

@ryhinchey I think I saw a messsage where you said you implemented the example, but can't find it again... Can you paste a link to that again? sorry to ask!

[popaprozac]

@brucou https://github.com/ryhinchey/crank-realworld-example-app

[ryhinchey]

@brucou here’s the discussion: #103 (comment)

I also thought I saw someone else post about implementing it. Someone else implemented it as well #50 (comment)

I’m not done with my version but am very interested in extracting out the router into a crank router package.

[brainkim]

Converting this to a discussion for housekeeping purposes!
@geddski I listened to your interview on the React podcast a while back and it was pretty inspiring.

[geddski]

Ah thank you!