Draft-js: What's difference between `entityRanges` and `inlineStyleRanges` of a block ?

Created on 6 Jun 2016  路  4Comments  路  Source: facebook/draft-js

I have seen the document and know ' links defined by entityRanges ' and ' bold style defined by inlineStyleRanges'.

But the ' bold style ' also can be seen as a entity which type is bold and data is font-weight: bold; ?

So what is difference between entity and inlineStyle? Why don't just use entity for everything?

Most helpful comment

The key here is to think of entities as _metadata_, not as style.

  • A bold piece of text might be just text that the user bolded via a keyboard command. This uses inline styles.
  • Alternatively, a range of text can be intended to represent some relevant metadata associated with the plaintext string -- a mentioned user, a symbol within the text, etc. An entity would be used here. The decorator for that entity, then, can be used to style that range of text.

Consider an imagined styled Facebook comment: "Hey Isaac, are you _sure_ you want to commit that change?"

Here, my name is a Facebook tag. There is metadata associated with my Facebook identity, and a decorator can render it as bold (or a link, like on actual facebook.com). That's an entity. In contrast, the italic text afterward doesn't have any metadata -- it's just styled text.

You _can_ use an entity to represent styles, since in essence style information is also just metadata on a text range. IMO, though, you'll end up duplicating built-in functionality.

All 4 comments

Inline styles are meant to only really decorate (i.e., style) the content in that range as-is. It has properties such as being an ordered set (e.g., BOLD, ITALIC) to control rendering.

Entities can render anything regardless of the content that it is applied to, and has the additional MUTABLE, IMMUTABLE, SEGMENTED properties.

@guitardave24 Thanks for your reply.

I decide to use MUTABLE entity with data bold to replace inline style bold, because it's will more friendly to our java engineer to understand. It's OK?

The key here is to think of entities as _metadata_, not as style.

  • A bold piece of text might be just text that the user bolded via a keyboard command. This uses inline styles.
  • Alternatively, a range of text can be intended to represent some relevant metadata associated with the plaintext string -- a mentioned user, a symbol within the text, etc. An entity would be used here. The decorator for that entity, then, can be used to style that range of text.

Consider an imagined styled Facebook comment: "Hey Isaac, are you _sure_ you want to commit that change?"

Here, my name is a Facebook tag. There is metadata associated with my Facebook identity, and a decorator can render it as bold (or a link, like on actual facebook.com). That's an entity. In contrast, the italic text afterward doesn't have any metadata -- it's just styled text.

You _can_ use an entity to represent styles, since in essence style information is also just metadata on a text range. IMO, though, you'll end up duplicating built-in functionality.

@hellendag got it, thanks.

Was this page helpful?
0 / 5 - 0 ratings