attaching metadata to text blocks

[forresto]

Are there any examples of:

• attaching metadata to text blocks
• attaching ui outside of the scribe element to text blocks in the scribe flow
• making image / youtube embed blocks look like they are in the text flow
  ?

forked from #89 conversation

[JeSuis]

So what we did at Refinery29 was model our editor after medium.com, we have text sections then also asset sections which shows a thumbnail and list details on the asset and what kind it is, it'll sit between your text sections. This is managed through an external asset editor.
On the front end its all json that's spit out.
Hope that helps some.

[rrees]

We've talked about it but we haven't done it yet. Would it be helpful to have an "official" place for the model data for the HTML?

[forresto]

@rrees yes please! The Grid would appreciate any guidance.

I have not quite figured out how to cleanly manage synchronization between our input (html+metadata) and Scribe's output html.

[forresto]

@rrees Any pointers where to start hacking this in now, before there is an official place?

[rrees]

We're discussing have a state that is controlled by the Scribe event emitter but thinking about a dirty hack that would work then create an Immutable Map during Scribe initialisation and a function that rewrites and reads the state and you should be able to hack something together than shouldn't be too painful to rewrite later.

My view is that Scribe needs to expose a read-safe state object to the plugins to drive their behaviour and the real discussion is who gets to change that state object and how

[forresto]

I'm ½ following you.

I have an empty Scribe instance, and start to add blocks of html from my data structure. The only hook out of Scribe that I see is the content-changed event.

It would help me if I could associate an id with each block added, that would get output with the content-changed event. Adding a new block would emit a different event with a new id (there could be a function to make a new id).

A placeholder block (empty div with dimensions) would make it possible to overlay media outside of the Scribe el that could still be selected, cut, paste, etc.

So, where should I look to hook in deeper than content-changed?

[forresto]

@rrees what do you think of the above request? Would there be any pitfalls to adding data-my-id attributes to the top-level blocks to keep them associated with our input data?

[JeSuis]

@forresto when we save our data the first time around they're assigned id's via the backend and it's loaded and re-saved that way. Any new blocks in an existing post have data id's assigned to them upon save.

There are many different options to saving this data, really depends on what your goals are.

If we're on the same page I can put a demo together, but would be a few weeks till I'd have time.

[forresto]

@JeSuis that sounds similar to what I'm going to try. Will ask for help if I can't get it working in a few days.

[JeSuis]

@forresto do you still need help on this? I can start messing around with some demos, or maybe people are interested in general.

[forresto]

I patched something together with a hydrate / dehydrate functions that keep the DOM in sync with the data model. It works, but feels a bit fragile. Would like to see other takes.

[JeSuis]

Ok I'll try to throw something together by the end of this weekend.

[JeSuis]

So here's the idea I was having if I was understanding you correctly.

You'll have your p blocks with some kinda of data attached to them.

<p data-id="1234" data-block-type="text" data-other-info="xxx">
text
</p>

but with each being assigned its own unique id on save

But with non text blocks, like a video

<p data-id="1234" data-block-type="video" data-asset-id="xxx">
Asset info
</p>

Then you use that asset id to pull in asset info

I think it's going to be a bit too crazy to have the actual embed in the text flow and you're better off having the asset open in a modal.

After all the text content loads on the page I insert a div after every p block that when hovered on, you can choose to insert your assets. Just like the medium editor.

On save you'll have to strip those out and I put the content into json, but on the backend its processed to save each block individually.

[jesteracer]

Any updates on this? I am trying to find a way to sign every p tag with a random digest, either adding id, or adding a data-attribute, but unfortunately can't get my head around it.

[hmgibson23]

It should be pretty simple to bind to the content-changed event and updated
each time that occurs.

On 5 August 2015 at 12:46, Boris notifications@github.com wrote:

Any updates on this? I am trying to find a way to sign every p tag with a
random digest, either adding id, or adding a data-attribute, but
unfortunately can't get my head around it.

—
Reply to this email directly or view it on GitHub
#366 (comment).

---

Visit theguardian.com. On your mobile and tablet, download the Guardian
iPhone and Android apps theguardian.com/guardianapp and our tablet editions
theguardian.com/editions. Save up to 57% by subscribing to the Guardian
and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com

This e-mail and all attachments are confidential and may also be
privileged. If you are not the named recipient, please notify the sender
and delete the e-mail and all attachments immediately. Do not disclose the
contents to another person. You may not use the information for any
purpose, or store, or copy, it in any way. Guardian News & Media Limited
is not liable for any computer viruses or other material transmitted with
or as part of this e-mail. You should employ virus checking software.

Guardian News & Media Limited is a member of Guardian Media Group plc. Registered
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. Registered
in England Number 908396

[JeSuis]

@jesteracer you're trying to do it on creation of the dom elements while working in the editor or when loading the content from your data source?

Either way it shouldn't be complicated, just a matter of which route to take.

[regiskuckaertz]

Just chiming in here: wouldn't a DOM observer be more appropriate in this case? There is already one at work in event.js, it could easily trigger events when nodes are added/removed and provide a fine-grained control over the content of scribe.el.

There is a problem though, as innerHTML is overwritten every time nodes are added/removed, which is some kind of brute-force solution that makes keeping track of nodes inside scribe.el very difficult. Plus there's the huge risk of a memory leak if plugins start to keep references to nodes that no longer exist in the DOM because they were overwritten by scribe.setHTML.

I guess what I want to say is that, from what I understand, an efficient/elegant solution to this problem will be hard to reach as long as scribe relies on innerHTML.

[theefer]

There was always a plan to use virtual-dom for all mutations and only apply the changes as patches, which would retain element identity in many cases (though cannot always be relied on). This hasn't been implemented yet unfortunately.

[oyeanuj]

@JeSuis I was wondering if you ever got around to writing the demo you offered above? :)

I am in a similar situation as yours, wherein I am trying to resemble Medium-like behavior but then trying to convert the content from the editor into a json through a normalizer plugin (which will scan for tags and a data attribute to match them to an element type (image, video, text, etc).

Seeing your demo would really help, if you have a moment.

Thanks so much!

[JeSuis]

@oyeanuj I hadn't cause he was basically already doing the same thing
I do have some code for the interface, the popup menu looks the same, I just have to separate it from some backend code that I can't post, so I may need to just work something new for that part.
What stack are you working in? Mine was done in PHP/JS

[oyeanuj]

@JeSuis Thanks for the quick response!

I am working on React/Redux/Rails-API stack but happy to see any stack code, even pseudo-code that explains your thinking :)

[JeSuis]

@oyeanuj
React implementation would be interesting to see.
I probably won't have time to look through things until the weekend.
So I'll get back to you in the coming week with what I have and we'll take it from there.