New home-page background

[MatteoRobbiati]

I have changed the back-ground style. The old images weren't compatible with all the screen's dimensions. I think this version works better.

The idea is to treat the background as a notebook sheet, on which we can write some funny stuff. An example follows:

For linking the first hero with the second one I used the "strategy" of the ringed notebook.

[alecandido]

I would suggest taking inspiration from a more modern looking SVG pattern: https://fffuel.co/

The notebook is nice and funny, but we risk the "open source design" impression of @scarrazza (in any case, the background color is too dark: little contrast reduces readability)

[MatteoRobbiati]

I am sorry to have done some new modifications in this PR.

The current status of the site purposed by this PR is quite similar to the previous one, but we have now the same background theme in all the pages (home-page, tutorials, each tutorial page). In the home-page we also have the notebook-sheet style as discussed before.

I am pretty sure that this won't be the final form, but I wanted to present something consistent for now.

I show here the current form of the home-page:

There is another small modification (sorry again for have done all in a single open PR): now the cards' contour is grey.

[alecandido]

Warning: Each child in a list should have a unique "key" prop.

Check the top-level render call using <div>. See https://reactjs.org/link/warning-keys for more information.
    at Tutorial (webpack-internal:///./components/Tutorial.js:11:21)
    at Tutorials (webpack-internal:///./pages/tutorials.js:47:22)
    at div
    at Layout (webpack-internal:///./components/Layout.js:12:19)
    at MyApp (webpack-internal:///./pages/_app.js:16:18)
    at ae (/media/alessandro/moneybin/Projects/Qibo/qibogang.github.io/node_modules/styled-components/dist/styled-components.cjs.js:1:13265)
    at StyleRegistry (/media/alessandro/moneybin/Projects/Qibo/qibogang.github.io/node_modules/styled-jsx/dist/index/index.js:449:36)
    at AppContainer (/media/alessandro/moneybin/Projects/Qibo/qibogang.github.io/node_modules/next/dist/server/render.js:308:29)
    at AppContainerWithIsomorphicFiberStructure (/media/alessandro/moneybin/Projects/Qibo/qibogang.github.io/node_modules/next/dist/server/render.js:337:57)
    at div
    at Body (/media/alessandro/moneybin/Projects/Qibo/qibogang.github.io/node_modules/next/dist/server/render.js:624:21)

https://reactjs.org/docs/lists-and-keys.html

[alecandido]

Tutorials do not have a background:

I don't know if this is intentional, but it looks like is missing something...

[MatteoRobbiati]

Tutorials do not have a background

Not missing, but different. You are right, thank you. I am thinking to change the strategy again, adding a flux background to all the pages (the goal is to have something nice for a first release, then we can change whatever we want).

[MatteoRobbiati]

https://reactjs.org/docs/lists-and-keys.html

If I have understood, this is a problem of identification using the map function. If what I said is true, what do you think if I open a dedicated issue and a separate PR?

[alecandido]

If I have understood, this is a problem of identification using the map function. If what I said is true, what do you think if I open a dedicated issue and a separate PR?

Fine for dedicated issue, but it is not a problem with map. The problem is that whenever you have a list of renderables (objects that are displayed on the page), you should add a key identifying each of them, otherwise if you change one React has no clue to find out which is changed, and it has to redraw the full set. If you identify them by keys (that should be related as much as possible to the role of the element), the moment you add/drop/modify one only that one is changed (DOM operations are invoked on that element alone), and the other ones are kept, with improved performances.

[alecandido]

I am thinking to change the strategy again, adding a flux background to all the pages (the goal is to have something nice for a first release, then we can change whatever we want).

I would recommend to stick to what you have right now, and we will take the time required to improve it later on. If you iterate too fast, you're performing a lot of attempts that are soon lost, eventually wasting your time.

It is readable as is, that's sufficient. In order to change it, we need a better criterion than what we like here and now, otherwise tomorrow we will change it again.

[MatteoRobbiati]

I would recommend to stick to what you have right now, and we will take the time required to improve it later on. If you iterate too fast, you're performing a lot of attempts that are soon lost, eventually wasting your time.

It is readable as is, that's sufficient. In order to change it, we need a better criterion than what we like here and now, otherwise tomorrow we will change it again.

Yes, it is true. I'll leave it as it is right now (after the last commit i did).

[MatteoRobbiati]

Fine for dedicated issue, but it is not a problem with map. The problem is that whenever you have a list of renderables (objects that are displayed on the page), you should add a key identifying each of them, otherwise if you change one React has no clue to find out which is changed, and it has to redraw the full set. If you identify them by keys (that should be related as much as possible to the role of the element), the moment you add/drop/modify one only that one is changed (DOM operations are invoked on that element alone), and the other ones are kept, with improved performances.

Yes, it is clear. In this case the only one situation in which I use a list of elements is when I fetch and render the markdowns in the [slug].js page. And this is done here using the map function. I'm going to open the issue, thank you again :)

[MatteoRobbiati]

If you all agree I can merge this. The key's problem will be tackled in another PR.

[andrea-pasquale]

Thanks @MatteoRobbiati. I think that the background in my laptop is not working properly. This is what I can see Is this correct?

[MatteoRobbiati]

Is this correct?

Yes it is. If you scroll the all page, do you see a flux of color from purple to orange? I think you can see it very well if you open the parameter shift rule example. It is really smooth, because the idea is to be as close as possible to white.

[andrea-pasquale]

Is this correct?

Yes it is. If you scroll the all page, do you see a flux of color from purple to orange? I think you can see it very well if you open the parameter shift rule example. It is really smooth, because the idea is to be as close as possible to white.

Thanks. I can see it. Good job!

[scarrazza]

I like too.