Code that I have to write in examples is different from "real" React code #324
Comments
|
I don’t know a good way to solve this. So far I use comments and define component classes inside examples: /*
import TableProvider from 'kao/components/TableProvider';
import * as sort from 'kao/util/sort';
import { Header, Body } from 'reactabular-table';
import orderBy from 'lodash/orderBy';
*/
class SortTable extends React.Component {
constructor() {
super();
const sortable = sort.sort({
getSortingColumns: () => this.state.sortingColumns,
onSort: selectedColumn => {
this.setState({
sortingColumns: sort.byColumn({
sortingColumns: this.state.sortingColumns,
selectedColumn
})
});
}
});
this.state = {
sortingColumns: {},
columns: [
{
property: 'name',
header: {
label: 'Name',
formatters: [sort.header(sortable)],
},
},
{
property: 'color',
header: {
label: 'Color',
formatters: [sort.header(sortable)],
},
cell: {
formatters: [fixtures.getColorName],
},
},
{
property: 'male',
header: {
label: 'Male',
formatters: [sort.header(sortable)],
},
cell: {
formatters: [male => male && <Icon type="check" />],
},
},
{
property: 'weight',
header: {
label: 'Weight',
formatters: [sort.header(sortable)],
},
cell: {
formatters: [weight => `${weight} g`],
},
props: {
className: 'text-right',
},
},
],
rows: fixtures.rows,
};
}
render() {
const { columns, rows, sortingColumns } = this.state;
const sortedRows = sort.sorter({
columns,
sortingColumns,
sort: orderBy
})(rows);
return (
<TableProvider columns={columns}>
<Header />
<Body rows={sortedRows} rowKey="id" />
</TableProvider>
);
}
}
<SortTable />
|
|
@sapegin yeah, that's annoying. Can we create a custom babel plugin that would strip off imports in examples if not needed? |
|
There’s no Babel on the frontend. And I think this behavior would be very confusing because for example you can use |
So, how is the rest of the code being transpiled to ES5?
Oh, probably I misunderstand the problem then. Why is |
With Buble. We can’t use Babel because it’s way too huge.
Because |
|
Gotcha. Thanks for clarifying. |
|
though it might not be the best way, and it might print relative path instead of the modules path that client is going to write. it seems that https://github.com/nerdlabs/react-docgen-imports-handler will put the imports in the documentation, and maybe comment the block so that buble doesn't throw errors?? |
|
Can we do anything here? Update the docs or something for example? If not I’d close it. |
|
Any plans to support |
|
@stereobooster We can discuss it as soon as Buble implements them ;-) So far I don’t see we can do anything here. |
|
Try the new 6.0.0 beta — it may solve some of this issue. |
|
@sapegin could you please explain this a bit? I read the release notes but I didn't see how it is related. |
|
I guess I meant importing examples from files. |
|
I think some time ago I have seen someone here pasting an example that used real React code, they wrote an entire component in markdown with class declaration, render method, all the good stuff. I can’t find it, but I think it was @okonet. I’ll try recreating that myself and will close this ticket if it works.
…Sent from my iPhone
On 4 Jan 2018, at 14:10, Artem Sapegin ***@***.***> wrote:
I guess I mean importing examples from files.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
There’s one in my comment at the very beginning of this issue ;-) |
|
I guess I misunderstood what that means back at the time.
…Sent from my iPhone
On 4 Jan 2018, at 14:35, Artem Sapegin ***@***.***> wrote:
There’s one in my comment at the very beginning of this issue ;-)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
It works! Wow. Very nice. Is this documented anywhere? |
|
I'm not sure, in any case worth documenting it more ;-) |
|
Yes, it is documented. https://github.com/styleguidist/react-styleguidist/blob/master/docs/Documenting.md#writing-code-examples. Very nice! |
Code examples are very useful as a part of documentation. They allow the reader to see how the "theory" of a component is applied in practice, and are the most useful when they can be easily put into a real application. With react-styleguidist, this works quite well in many cases: you write your code exactly as it should be written and your reader can just copy-paste it into their app and get it working.
Unfortunately, it doesn't work for more complex components that require some sort of external "scaffolding" to work, or for complicated setups, for example, with HOCs and theming. RSG has
initialStateandsetStatewhich work great but cannot be copy-pasted into a real React application: they have to be rewritten into some sort of constructor method andthis.setStatecalls.Don't get me wrong here though, I'm not saying that RSG is buggy or does its job poorly. It works great, I'm quite happy that I don't have to write all the
import React from 'react';fluff around most of my components most of the time and can just plop a short JSX one-liner and see it "just work". The task of rendering arbitrary code is hard, and it is even harder if you want to have some sort of magical balance between writing short code and writing complicated code. But it would be great if the code in my examples was closer to what my users have to write in their projects.I don't have a solution at hand and I don't even know if there is a solution for this issue, given all the restrictions that RSG has. So let's talk about this, maybe? Does anybody here have this problem, and how do you deal with it? Is there anything that could be added to RSG to make it even better in this regard?
The text was updated successfully, but these errors were encountered: