For the case of a football website, you could have blocks which display or edit data which doesn't need to be tied to football specifically, but can be used to build/display the football website, e.g. (I'm just going to say 'display' but assume these can all 'edit' the same data):
- an 'Organization' block that displays an org name, logo, HQ location, etc (for displaying info on teams)
- a 'Table' block that takes any dataset and can allow you to sort, filter, the data in it (for displaying stats)
- an 'EventCalendar' block that takes a list of fixture dates and details, maybe allows you to view it as a list or on a calendar
these blocks wouldn't care that you were using them for football specifically - just that you were providing them data in the structure they can work with. We're not claiming that these generic blocks would do everything you wanted - but they'd get you a lot of the way there.
I appreciate that you can use whatever JS you want when constructing custom elements.
To date we've been looking at how apps can deal with different ways in which blocks can be exposed to the app, but haven't ruled out specifying that they must be exposed in a fixed way - this would make it more consistent, at the cost (which may well be small and largely automatable) of requiring authors to wrap their block, e.g. with a custom element definition.
I'd be interested to talk in more detail about how that might work with relation to the current web component spec and future plans / other work in train: [email protected] if you're up for it
> iframes are cumbersome of course, so it would have been interesting to see the protocol focus on making them more seamlessly integrate with the embedding context with a standard postMessage protocol for things like securely forwarding content sizes (for auto-resizing the frame), events, and styling information across the frame boundary.
That is one approach - what we've experimented with is having applications load their own thin 'block handler' code in an iframe, which then renders the block and does the message passing with the parent window. This way blocks don't have to know whether they're framed or not, and applications can choose not to frame blocks, e.g. because they're all trusted and they don't want the additional overhead.
As David says, very interested in any and all thoughts on this subject, as it's important to get right. Like many aspects of the spec, the thinness of the current material is more a reflection of the early stage of the project than a view that it is unimportant / doesn't need further work.
The idea is more that you build your website out of blocks which allow the display or editing of defined data structures - so you search for blocks which are compatible with the data you want to work with (which can be done programmatically), and swap them around depending on what the user wants to do (display x, edit y).
The goal is that blocks can be dropped into applications to provide the functionality to display x or edit y, without requiring configuration, because the operations they will use to work with data, and the ways in which constraints/valid data are described, are common across all blocks and supporting applications.
We're focusing on the browser context at first, but expect the principles of the interface between a block and application (if not the implementation details) should be applicable to other environments - very briefly mentioned here https://blockprotocol.org/docs/faq#what-about-non-web-contex...
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 when actually loading a block).
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.
> 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.
As it stands we're reluctant to dictate the internal implementation of a block, on the assumption that we can abstract away dealing with different implementations - but I agree that the extra requirements for non-native implementations are a downside. We're also conscious of multiple implementation approaches potentially leading to fragmentation, with React-implemented blocks limited to applications who are happy to ship React, and other variations. It's a tricky balance to strike between freedom for the block author (i.e. can they implement it how they want, or must they use X) and work for the embedding application (how many different flavours of block implementation do they need to deal with - albeit we can provide libraries for this).
> 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.
Right - the components describe their interface, but there's no standardization of the shape of the interface. e.g. the format for Web Components you describe allows components to describe their methods, but the Block Protocol aims to standardize what the methods actually are - so that you don't need to read the API of a component to plug it into your app or understand what the methods do.
I believe the two projects are entirely compatible and complementary: a Web Component could have a thin wrapper around it to convert its methods to the expected name/signature specified by the Block Protocol. But I don't think Web Components as they are, in isolation, meet the aims of the BP.
> Don't get me wrong, richly-typed presentational components would be a big improvement. But I don't think they should be the end goal (unless perhaps you're in the blog-writing software business).
At this early stage we'd be delighted with a big improvement in component standardisation/typing, and for now we're focusing on building on existing ways of representing semantic information in order to achieve that. I agree that there's a lot of scope beyond that for improvements.
> How do we design a semantic typing system for real-world data that is amenable to the inevitable need to evolve or amend the schema, or leave off certain fields from a type instance, or tack on a few extra fields? Should our applications eschew canonical types (like schema.org's Person) in favor of a ducktyping approach (I don't care if you give me a schema.org Person, or a blockprotocol.org Person, or a notpachet.org Dog, as long as the blob has a numeric field for the "age" key?
We may be indulging in cake-and-eat-it-ism, but we think the Block Protocol can allow for both.
The proposal is for the structure of entities to be represented in JSON Schema. As JSON Schema is just a set of constraints, you can take a blob of data and calculate 'does this data meet this set of constraints' (i.e. structural/duck typing). So if a Block has a schema which says that it requires a single field 'age: number', it doesn't matter what class the data you have belongs to, you can throw it into the block if it has that field. We have an API that will accept data objects and respond with blocks which have a schema the data is consistent with (not necessarily matches).
This doesn't preclude limiting certain operations/blocks to _only_ data which is linked/belongs to a specific schema/type (i.e. nominal typing), rather than simply satisfying its constraints. And there are circumstances in which not dealing with additional fields that a type might have is an issue, although for presentational or editing blocks that don't claim to be a 1:1 map onto a specific type, I think it's fine and useful for them to be able to present/edit a subset of fields from various types.
> You could argue HTML is already a universal language that includes semantic 'blocks'. Is the block protocol a collection of HTML elements grouped together to form higher-level blocks?
That's part of how blocks are implemented, but we already have higher-level blocks made from HTML elements in the form of Web Components, and various JS libraries.
The protocol is aimed at building on this to standardise how those higher-level blocks communicate with the applications using them.
> Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
This is an area of the spec we need to develop - the goal is a light-touch way of blocks appearing visually consistent with the application around them, while leaving the rest up to the block. The current proposal is some kind of theme variables the application can pass to the block for use, but needs more thinking - https://blockprotocol.org/spec/block-types#styling - and we appreciate any thoughts.
How can the block protocol avoid [issues with current embeds]?
Partly by focusing on standardising how you pass data back and forth between the block and the application: blocks which aren't of the application, and don't need to know about it, but allow users to edit data that lives in the application.
Agree that slow loading is an issue to address, which is easier to deal with when you control all the source code, less so when you're pulling in blocks from elsewhere - the first step in this is for blocks to be able to leave the provision of common libraries to the embedding application, so that each block isn't shipping React (or whatever).
The parties to the protocol (in this early form, with a web focus) are:
1) an application which is generating a web page, and
2) a block of functionality which is part of that page.
Or the authors of each.
Where is state?: blocks can have their own local state, but to persist data beyond the session should make use of the operations defined in the spec to pass data back to the application (the standardisation of what these operations are and what they do is a key part of the spec).
Where is the UI code?: I might've misunderstood this question, but - a block should have a package which contains code for rendering its UI and dealing with data to/from the application embedding it. The application can then either pull that code at runtime (e.g. from a CDN) when a user requests to use a certain block, or include it as a library and ship it with the application.
We will be providing these, yes - we want to minimise the amount of work embedding applications have to do in setting themselves up to render blocks, as well as making it easier for block authors to write them.
At the moment, yes - we want to figure out the principles of application/block interaction in a web context first, and then move on to other environments. The principles should be transferable, although some of the 'how are they implemented' won't be (https://blockprotocol.org/docs/faq#what-about-non-web-contex...)
The comment above you is right that 'handling blocks implemented in different ways' (in a web context) is one of the mushier parts of the spec, and it's something we need to do more prototyping and refinement of.
This is correct: it's the standardization of the interface between blocks and things using them, which includes structure in the data being passed back and forth, and the structure of the interface itself (e.g. what operations are available).
We do want to promote the free exchange of structured data, and to have data captured and marked up according to some structure - we also want to promote the portability and easy-of-setup of UI components.
Our FAQ illustrates how we relate to and intend to use existing standards - https://blockprotocol.org/docs/faq - we'd be interested in any others you think worth building on.
We want to fit into the existing semantic web tech rather than reinvent it - there's a FAQ here which hopefully helps to clarify: https://blockprotocol.org/docs/faq
- an 'Organization' block that displays an org name, logo, HQ location, etc (for displaying info on teams)
- a 'Table' block that takes any dataset and can allow you to sort, filter, the data in it (for displaying stats)
- an 'EventCalendar' block that takes a list of fixture dates and details, maybe allows you to view it as a list or on a calendar
these blocks wouldn't care that you were using them for football specifically - just that you were providing them data in the structure they can work with. We're not claiming that these generic blocks would do everything you wanted - but they'd get you a lot of the way there.