Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation updates for 0.16 #864

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

Conversation

davesnx
Copy link
Member

@davesnx davesnx commented Nov 20, 2024

@@ -113,7 +113,7 @@ Reason also always opts for the safest form of a given hook as well. So `React.u

## Hand-writing components

You don't need to use the `[@react.component]` declaration to write components. Instead you can write a pair of `foo` and `fooProps` functions such that `type fooProps: 'a => props and foo: props => React.element` and these will always work as React components! This works with your own version of [`[@bs.obj]`](https://melange.re/v2.0.0/communicate-with-javascript/#using-jst-objects), [`[bs.deriving abstract]`](https://melange.re/v2.0.0/communicate-with-javascript/#convert-records-into-abstract-types), or any other function that takes named args and returns a single props structure.
You don't need to use the `[@react.component]` declaration to write components. Instead you can write a pair of `foo` and `fooProps` functions such that `type fooProps: 'a => props and foo: props => React.element` and these will always work as React components! This works with your own version of [`[@mel.obj]`](https://melange.re/v4.0.0/communicate-with-javascript#using-js-t-objects), [`[bs.deriving abstract]`](https://melange.re/v4.0.0/communicate-with-javascript#using-external-functions), or any other function that takes named args and returns a single props structure.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we may need some kind of way to centrally update the melange version that we talk about.

include React.Context; // Adds the makeProps external
let make = React.Context.provider(themeContext);
```

That will give you a `ContextProvider` component you can use in your application later on. You'll do this like you'd normally would in any React application.
```reason
/** or inside a any other module */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/** or inside a any other module */
/** or inside any other module */

};
```

That will give you a `ContextProvider` component you can use in your application later on, by wrapping any component with `ContextProvider`, to have access to the context value inside the component tree. To know more about Context, check the [official React documentation](https://legacy.reactjs.org/docs/context.html) and [when to use it](https://react.dev/learn/passing-data-deeply-with-context).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we update the legacy doc to https://react.dev/reference/react/createContext?


- `renderToString` : `React.element => string`
- `renderToStaticMarkup` : `React.element => string`

More info about `ReactDOMServer` can be found in the [official React documentation](https://react.dev/reference/react-dom/server).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should add a small section about ReactDOMServerNode, which you can get by depending on reason-react.node

@@ -15,13 +15,13 @@ This likely means that:
This is a common mistake. Please see Melange's [Import an ES6 Default Value](https://melange.re/v2.0.0/communicate-with-javascript/#default-es6-values). Aka, instead of:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw you updated the link to point to v4 above. we should likely update the melange doc links across the entire docs to be consistent, in that case.


```reason
/* we create a type for the action */
/* we create a type for the action, but action can be anything */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/* we create a type for the action, but action can be anything */
/* we can create anything as the type for action, here we use a variant with 2 cases. */


/* and do the same for state */
type state = {count: int};
/* similarly on 'state', it can be anything. In this case, it's an int */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/* similarly on 'state', it can be anything. In this case, it's an int */
/* `state` could also be anything. In this case, we want an int */

};
```

## Using Event values with useState
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is duplicated from docs/usestate-event-value.md. are you planning to delete that page?

@@ -2,7 +2,11 @@
title: Working with Optional Data
---

If you're coming from Javascript, optional data can be a real pain in the butt. ReasonML removes a *whole class* of `null` and `undefined` bugs which makes your code WAY safer and easier to write, but it takes some good examples to get you there :smile:
If you're coming from JavaScript, optional data can be a real pain in the butt. ReasonML removes a *whole class* of `null` and `undefined` bugs which makes your code safer and easier to write, but it takes some good examples to get you there :smile:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If you're coming from JavaScript, optional data can be a real pain in the butt. ReasonML removes a *whole class* of `null` and `undefined` bugs which makes your code safer and easier to write, but it takes some good examples to get you there :smile:
If you're coming from JavaScript, optional data can be a real pain. ReasonML removes a *whole class* of `null` and `undefined` bugs which makes your code safer and easier to write, but it takes some good examples to get you there :smile:

we can use this opportunity to remove some of this language too.


ReasonML uses the `option` type to represent optional data. As defined in the standard library [here](https://reasonml.github.io/api/Option.html).

Here there are a few examples of how to work with optional data in ReasonML, using the [Belt](https://melange.re/v4.0.0/api/re/melange/Belt) library from `melange.belt`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Here there are a few examples of how to work with optional data in ReasonML, using the [Belt](https://melange.re/v4.0.0/api/re/melange/Belt) library from `melange.belt`.
Here are a few examples of how to work with optional data in ReasonML, using the [Belt](https://melange.re/v4.0.0/api/re/melange/Belt) library from `melange.belt`.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ReactEvent -> React.Event in docs
2 participants