Comments (11)
While AutoGroups
seems to be legal, AutoHeaders
is something too specific, related to Table representation, which core not limited to. We could call it AutoTitles
, or try to make it more universal, like taking additional prop with field key which would be mapped to children.
from autoviews.
AutoHeaders
orAutoTitles
it might beAutoViews
when you useJSONSchema
asdata
: fields of the object and optional titles becomesdata
. I think we need to explore and think about this idea a bit more. The proposed option wouldn't work for bindingAutoHeaders
inComponentsRepo
whenAutoFields
andAutoItems
are bindable without necessity to definechildren
AutoGroups
it is basically multipleAutoFields
with ability to wrap them.
Both components are nice to have thing to hide direct usage of low level utils, but not yet sure they are the similar to AutoItems
and AutoFields
as they are also very low level.
Let's have a call about this proposal and try to think together on the best api. The problem though is very relevant.
from autoviews.
The reason I advocate for those two components is that is separates the higher level elements (auto items, auto groups, etc) with the low level concepts, making documentation way simpler and understanding the product simpler for a new user
from autoviews.
Adding more notes -
I can easily see how we can make AutoHeaders
more generic by turning it into AutoSchemaFields
which basically accepts the JSONSchema node for the map function.
The example from above turns into the following
<AutoSchemaFields {...props}>
{(schemaField, i) => <TableCell key={i}>{schemaField.title}</TableCell>}
</AutoSchemaFields>
from autoviews.
Then why do we need a React component AutoSchemaFields
, it could be just utility.
from autoviews.
Regarding AutoHeaders
.
Here is how I see it today. It is combination of 2 things:
- some utility that converts schema to the data considering UISchema (remove hidden, order, etc..), builds a schema for that converted schema automatically.
- Ordinar AutoView usage.
Example: https://codesandbox.io/s/autoheaders-7xss6o?file=/src/AutoHeaders.tsx
Why I think it is important to to have schema=>data conversion?
- it is in fact what is needed
- there is no way with headers auto-events would work properly, so it should be clear that schema and data are new and if it is needed to have onclicks/onchange(s): they should consider this transformation.
I don't see any better way. This looks good I think.
@yoavaa and @Fer0x plz take a look
from autoviews.
I want to understand - your suggestion is basically the structure below
The second part is great, but the first is too strange, and the two schemas convertedSchema
and convertedSchema2Data
are again very strange.
The problem with the below is that the intent gets lost with a too verbose code.
- define the repo
const tableHeadRepo = new ComponentsRepo("tableHeadRepo")
.register("array", {
name: "tableHeaed",
component: (props) => (
<thead>
<AutoItems {...props} />
</thead>
)
})
.register("object", {
name: "tableHeadCell",
component: (props) => <th>{props.data.schema.title}</th>
});
- the table component is then
new ComponentsRepo("complex")
.register("array", {
name: "table",
component: (props) => {
return (
<table>
<RepositoryProvider components={headRepo}>
<AutoView schema={convertedSchema} data={convertedSchema2Data} />
</RepositoryProvider>
<tbody>
<AutoItems {...props} render={(item) => <tr>{item}</tr>} />
</tbody>
</table>
);
}
})
.register("object", {
name: "tableRow",
component: (props) => (
<AutoFields {...props} render={(item) => <td>{item}</td>} />
)
})
from autoviews.
What I am trying to say is that it looks too complicated.
What I am looking for is something like
new ComponentsRepo("complex")
.register("array", {
name: "table",
component: (props) => {
return (
<table>
<schemaAsData {...props} path={items} >
<AutoItems {...props} > // the items here are the schema fields of the item
</schemaAsData>
<tbody>
<AutoItems {...props} render={(item) => <tr>{item}</tr>} />
</tbody>
</table>
);
}
})
from autoviews.
@yoavaa in terms of AutoViews if data is completely different so it should be different AutoView scope with own props /repo/repositoryContext. Code might be rewritten to something like this:
new ComponentsRepo("complex")
.register("array", {
name: "table",
component: (props) => {
return (
<table>
<thead>
<SchemaAsData {...props} path="/items">
{headerProps => <AutoItems {...headerProps} render={item => <th>{item}</th>} />}
</SchemaAsData>
</thead>
<tbody>
<AutoItems {...props} render={(item) => <tr>{item}</tr>} />
</tbody>
</table>
);
}
})
But anyway, <SchemaAsData />
should contain RepositoryProvider with some different repo.
from autoviews.
@yoavaa the problem in your example is auto-passing props.
which is impossible, as the data and schema are different.
what if prop contains onClick
, or other things that relates to original data structure.
from autoviews.
I think we are getting to an interesting direction.
The concept of schema as data, which replaces the props and can use a different component repo looks like a good ackaging for headers.
Given we translate schema to data, we can also translate using the UI schema for field ordering and filters, or create an equivalent UI schema to do so.
Anyway, it feels like something that takes a good form
from autoviews.
Related Issues (11)
- Improve predicate docs HOT 1
- More context for predicates HOT 1
- Render schema validation errors
- Composing getNodeType
- Remove lodash from peerDependencies HOT 1
- Change AutoItems interface HOT 1
- Idea: Move docs to the root of repo HOT 4
- Project setup
- Support `prefixItems` as Tuples HOT 2
- Make validation external / peerDependency
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from autoviews.