Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Many have tried - very recently - and seemingly stalled or failed at creating something like this with wide adoption, most notably Tim Berners-Lee with the SOLID protocol
https://solidproject.org/
https://solidproject.org/TR/protocol
The roadblock is seemingly always getting major tech companies to accept it as a valid means of accessing user data.
The amount of times I've heard about SOLID on NPR or other popular mainstream newscasts only to garner little to no support is astounding. Definitely take note where others have seemingly failed here because it's an uphill battle.
If you want to promote portability, then blocks should be web components based, full stop. React-based blocks won't be usable without setting up React on the page.
I think the FAQ around leaves a lot more open questions. Like:
> but they do not standardize the interface between those blocks and the applications using them
I'm not sure this is entirely true. Most reusable components these will have an interface described by a type system - this is how IDEs offer code completion and JSX and other template systems are type-checked.
In the Web Components Community Group we're also standardizing a format for describing the entire interface of a web component, including its attributes, properties, events, methods, CSS variables and parts, etc. This is called the Custom Element Manifest: https://github.com/webcomponents/custom-elements-manifest
Instead of being tied to json-ld, the manifest just documents what JS/TS type a property, etc., has. If a component has a person property that accepts a Person type, a tool can understand that.
This manifest will give tools like catalogs, linters, and visual UI builders enough information to do high-level operations like generate demos, lint templates, assemble components without code, etc.
1) The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it on the to-do list?
It's on the to-list indeed - we are going to add links to the source of blocks. The package for distribution will typically be minified and less illuminating, although we can look to expose that too (as well as making it available for request via the API).
2) What's going on with the type signatures here?
The type signatures on functions in the spec definitely need cleaning up to be consistent and more helpful. They are pseudo-code. There are TypeScript types for them (https://github.com/blockprotocol/blockprotocol/blob/main/pac...) which won't be much use to you, but I am including in case they are of someone else.
The schema you mention in the Hub is autogenerated from the TypeScript interface for the block, which can lead to weird artefacts of the sort you identify. We need to add custom codegen to better handle this. It should valid JSON Schema.
Exactly what I was thinking. The Semantic Web done the heavy lifting of defining general schemas (https://schema.org) and extending JSON (https://json-ld.org) and yet people don't subscribe to it. On the other hand, it has a lot of historical baggage (RDF, old schemas) that maybe a new standard can actually be better
I've read and perused this, and I have some specific questions.
1. According to the spec[0], a "block package" is "a collection of files making a block type (which is 'a definition and implementation', the schema and the code) available for use by embedding applications, including its source code and accompanying metadata." However, when I browse to a "block"/"block package" in the Block Hub[1], I'm presented with a demo of the "block package" in the form of a concrete "block", a view of example data being provided to this "block", and a view of the schema of this "block". However, if this is meant to be a view of the "block package", shouldn't I also be able to find my way to the rest of this "block package", i.e. where do I view the implementation code? The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it on the to-do list?
2. What's going on with the type signatures here? I see a lot of what look like type signatures, in both the spec and the schemas. In reading the spec, it seems like the type signatures are being used pretty loosely, maybe as pseudo code of a sort, as I don't see them being rigorously referred to. For example, I see that in "Specification > Block Types > Entity type functions"[2] under `createEntityTypes` it refers to accepting a type of "CreateEntityTypesAction" (no type signature), but then lower down it refers to accepting a type of "CreateEntityTypesAction", but then says that the shape of that entity is just two hard-coded fields, with no reference to the generic type "T". What's going on here? Then if I view an actual block in the Block Hub[1], I see that the schema for that block also has definitions for entities with some kind of type signature 'something' going on e.g. "#/definitions/Record;}>". Maybe those are for use with something like TypeScript? I'm not familiar with TypeScript, so I don't know how to parse those, though I do know that they're not specifying anything at the level of "JSON Schema"[3], so I assume they're related to either something in the spec or something in the implementation, or both. What's happening here? Are these types in the schema owned by the implementation (e.g. they're used by the source code of the implementation for JSX or something?), while the types in the spec are merely pseudocode? And if there's already a pattern where additional layers of features such as typing/templating are being shoved into the schemas of Blocks, might this make interop between blocks more difficult in the future?
[0] - https://blockprotocol.org/spec#terminology
[1] - https://blockprotocol.org/@hash/table
[2] - https://blockprotocol.org/spec/block-types#entity-functions
[3] - https://json-schema.org/