This PR is in relation to #46. It implements the proposed changes.

This commit adds a Basic Block type. The struct holds the common fields that Notion blocks have like ID, Creation data, etc. It implements the Block Interface. As a result, first, the embedding types will have access to all of the same fields, and second, will also implement the block interface.

parent is databaseParent or PageParent

use a map format like

{
    "parent": {
        "database_id": "abcd"
    }
}

Current in sdk is

{
    "parent": {
        "type": "database_id",
        "database_id": "abcd"
    }
}

While using the lib, I noticed that a bunch of properties have some fields typed with interface{}:

• DateProperty.Date
• PeopleProperty.People
• CheckboxProperty.Checkbox
• ...

While technically, this doesn't prevent to use the API, it still shifts the work on the library user to handle those fields. Is there a particular reason motivating this choice?

From my understanding so far, the API data structures for these fields are rather straightforward, thus it should be simple to handle those cases.

I don't want to meddle with unwanted PRs, so I thought it'd be best to first discuss things here!

This is response to #51.

This adds the PropertyArray type and defines an unmarshalling function for it. This will allow for the unmarshalling of Rollup arrays.

This also moves some switch logic in parsePageProperties to a decodeProperty function which so it can be used in the unmarshalling of PropertyArray.

Currently there is a problem with unmarshalling into a Block interface, since the decodeBlock function is unexported. This is an issue when trying to use the Block type outside of the API, such as loading a Block from a JSON file. A Block itself cannot be defined to unmarshal into, as it is an interface and can't be a receiver, but a []Block can be, as done here.

[]Block cannot be unmarshalled into as it is an interface. This defines a Blocks type, which is just a []Block, and an UnmarshallJSON method so that a JSON string/byte slice can unmarshall into a []Block.

example code

	key := "token token token"

	client := notionapi.NewClient(notionapi.Token(key))

	childrenvv := notionapi.ParagraphBlock{
		Object: notionapi.ObjectTypeBlock,
		Type:   notionapi.BlockTypeParagraph,
		Paragraph: notionapi.Paragraph{
			Text: []notionapi.RichText{
				{
					Type: notionapi.ObjectTypeText,
					Text: notionapi.Text{
						Content: "AAAAAA",
					},
					Annotations: &notionapi.Annotations{
						Bold:          true,
						Italic:        false,
						Strikethrough: false,
						Underline:     false,
						Code:          false,
						Color:         "",
					},
				},
				{
					Type: notionapi.ObjectTypeText,
					Text: notionapi.Text{
						Content: " BBBBB",
					},
					Annotations: &notionapi.Annotations{
						Bold:          false,
						Italic:        false,
						Strikethrough: false,
						Underline:     false,
						Code:          false,
						Color:         "",
					},
				},
			},
		},
	}

	req := notionapi.AppendBlockChildrenRequest{Children: []notionapi.Block{childrenvv}}

	appendChildren, err := client.Block.AppendChildren(context.TODO(), "blockId(is a page)", &req)
	if err != nil {
		panic(err)
	}

	fmt.Println(appendChildren)

get error : interface conversion: interface {} is nil, not string in github.com/jomei/[email protected]/block.go:537

According to the notion js definition for RichText, we have:

type TextRequest = string

type RichTextItemRequest =
  | {
      text: { content: string; link?: { url: TextRequest } | null }
      type?: "text"

from: https://raw.githubusercontent.com/makenotion/notion-sdk-js/main/src/api-endpoints.ts

but the definition in the current implementation was that the Link was a string instead of an object containing a URL.

As an example, I have a page with:

        "text": {
          "content": "Gastbsy",
          "link": {
            "url": "https://www.gatsbyjs.com/"
          }

This PR changes the type - and I was able to confirm that it is working for my notion page.

PS: my vscode does some formatting automatically. It also caught a typo (omtiempty)

Thanks for developing this SDK within a few weeks after the public beta launch!

Notion doc:

Sorts are similar to the sorts provided in the Notion UI. Sorts operate on database properties or page timestamps and can be combined.

It seems that Property Field of SortObject should be omitted in case of an empty value, to allow sort by page timestamps

Otherwise notion API returns:

{
    "object": "error",
    "status": 400,
    "code": "validation_error",
    "message": "Could not find sort property with name or id: "
}

HiHi master, thanks for your SDK!

The official API supports updating the icon and cover of the page. Could you update the SDK to support this function ?

This is for #45

The following block types were added:

• Breadcrumb
• Column and Column List
• Synced Block
• Link to Page
• Template
• Equation
• Link Preview Based on https://developers.notion.com/reference/block and testing.

The JSON decoder doesn't know how to parse the type []Block of children attributes.

type ListItem struct {
	Text     []RichText `json:"text"`
	Children []Block    `json:"children,omitempty"`
}
...
type NumberedListItemBlock struct {
	Object           ObjectType `json:"object"`
	ID               BlockID    `json:"id,omitempty"`
	Type             BlockType  `json:"type"`
	CreatedTime      *time.Time `json:"created_time,omitempty"`
	LastEditedTime   *time.Time `json:"last_edited_time,omitempty"`
	HasChildren      bool       `json:"has_children,omitempty"`
	NumberedListItem ListItem   `json:"numbered_list_item"`
}

This is due to Block beign an interface and JSON can't resolve dynamically the Block type.

One way to solve this is creating a Block struct with the common attributes, decoding it first and then resolving the concrete type dynamically.

Thx for the cool package!

Looks like the is_inline field was added in https://developers.notion.com/changelog/changes-for-june-6-june-20-2022 but I don't see suppport for in DatabaseCreateRequest. Of course I may just be missing it somewhere.

I'd be willing to open a PR supporting is_inline on DB creation if there's interest.

Is it possible to add support for returning pointer to BasicBlock which is part of every block type? This would help editing the basic block field without needing to type cast Block interface to concrete block type object. Something similar to this

type Block interface {
	...
        ...
        ...
	GetBasicBlock() *BasicBlock.  <-  New addition
}
...
...
...
func (b *BasicBlock) GetBasicBlock() *BasicBlock {
	return b
}

If any client wants to edit something from BasicBlock which is common to all blocks, the client would always need to type cast the block interface to a particular block type and edit the BasicBlock info even when the client is not making any change specific to given block type.

After going back and forth on #9, it feels like making sure the API reference is properly implemented is a quite meticulous task that is quite error prone and may introduce vicious bugs that will be hard to track down.

The official JS SDK has all the API types properly defined in Typescript, which could be used to generate those structs: https://github.com/makenotion/notion-sdk-js/blob/main/src/api-types.ts

An example on how to achieve that can be found in gopls, which uses that approach to handle the structs that deals with the Language Server Protocol: https://github.com/golang/tools/tree/master/internal/lsp/protocol/typescript

I may give it a try in the upcoming days, I'll post here if I do!