Maybe incorrect code for the update function of hello-world example?

[Zaid-Ajaj]

Hello, The new docs site look really cool! I noticed something in the hello-world sample and please correct me if I am wrong. if Model = string then the update must have signature Model -> Action -> Model but the update function in docs seems to return a tuple Model * 'a list

// isn't this update : Model -> Action -> Model * 'a list?
let update model action =
  match action with
  | ChangeInput str -> str, []

Shouldn't it be just the following?

let update model action =
  match action with
  | ChangeInput str -> str // not str, []

[MangelMaxime]

Hello @Zaid-Ajaj , glad you appreciate the new docs site :).

The signature in the sample is Model -> Action -> Model * 'a list because the samples are sub applications of the website actually. They are not standalone.

You are true we could simply have an update function with the signature Model -> Action -> Model for this sample if it was standalone.

Writing the new docs website was at first to reduce the gape between sample and real case application. This is why the docs site is written using Fable-arch itself. And because I always had people confused because of "SimpleApp" concept I decided to work with "StandardApp" for the samples. We all have been started by using "SimpleApp" and at a moment we was somehow lost or hacking the structure to add some async code because we was only aware of createSimpleApp function.

I think by introducing only StandardApp we can reduce this gap. I also think that when writing a real case application we would always need async code but perhaps I'm wrong.

My question is do we need to show "SimpleApp" or perhaps explain a little better why we got to return [] at the end.

[Zaid-Ajaj]

The docs site is a nice example of using navigation with subapps but IMO, I don't think that the docs should be showcasing how the docs are made, but rather showcase standalone small samples that someone could follow, copy-paste into his/her editor and build. The old site had these independent samples that I could follow and understand by just looking at the types but here it's a bit confusing. I have a couple of suggestions:

• We make every sample independent
• Add type signature to functions for clarity using comments for example
• Explain what this model-update-view architecture is
• To showcase a StandardApp with async code, we should make a StandardApp sample (standalone as well)

What do you think?

[MangelMaxime]

We make every sample independent

The problem with standalone samples is how to start/stop them. (The docs site is now an SPA) After, we could also let them be like there are at the moment and when building the docs website generate a standalone project for each of them. If the user want to work with them, he simply click on "Download sample" and he will received a zip folder with everything needed to work.

This should not be hard to do, as we only need to change the sample.fsx file content with the sample code. All the rollup, build.js, package.json being the same code for all the samples.

Now that I think of the "generate" solution I kind of like it because the more samples we will have in the repo, the more painful it will be to keep each package.json file etc. However if all the boilerplate is generated from a template it's become really easy.

I will try to work on this solution during this week to propose a draft and discuss it together if you are ok :)

Add type signature to functions for clarity using comments for example

The signature using comments are a good idea has we don't have the tooltip now.

Explain what this model-update-view architecture is

Planned for the docs section.

To showcase a StandardApp with async code, we should make a StandardApp sample (standalone as well)

Planned

Thanks for your suggestions :)

Also one question, if we want to give a try to the generate solution. Do you want me to convert your "calculator" sample or do you want to give it a try yourself. I can explain you how to do it. (Better on gitter)

[Zaid-Ajaj]

The problem with standalone samples is how to start/stop them. (The docs site is now an SPA)

After taking a closer look at the docs site and if I understand it correctly, this is a SPA as one app and you are composing the samples as sub-views. Does that mean you can't compose larger apps of small ones and only the views are composable?

Also one question, if we want to give a try to the generate solution. Do you want me to convert your "calculator" sample or do you want to give it a try yourself. I can explain you how to do it. (Better on gitter)

I will give it a try myself and let you know if I get stuck :)

[MangelMaxime]

I am not sure to understand your first question. The samples can be complexe we will just by convention contains them to there sub url and make them fit the current layout.

I have a complex sample in progress to show this.

[MangelMaxime]

Ok, I find a solution to make the samples standalone. We will load them inside an iframe. (Codepen.io is working like that).

Now I just need to think the directory architecture and we should have the next step ready for easier contributions.

Also, I will rework the "Samples" page to link the samples/demo in another way. Problem with using the navbar is width of the website is limited and not always the same for all the computers.

[Zaid-Ajaj]

Sounds promising, I will look into it too :)

[MangelMaxime]

New docs site published