Rich text as a field type

[kkoppenhaver]

Hey there, thanks for this package, it's working great!

Just wondering if adding rich text as a supported field type is on the roadmap?

For example, we have a repeatable field with a headline (text) field and a content (textarea) field. We would love this to be able to be a rich text field like laravel supports natively for fields that aren't repeaters. See: https://nova.laravel.com/docs/1.0/resources/fields.html#trix-field

I'm happy to look into working on a PR for this, as we'll likely have to do it for a project we're working on anyway.

[fourstacks]

Hi @kkoppenhaver - glad you find the field useful! If I'm being honest the chances of me finding time to whip up a rich text field like you describe is pretty slim for the foreseeable future - bit too much else going on. If you fancy giving it a go yourself however and don't mind submitting a PR that would be great. Good luck!

[slovenianGooner]

I might have a go at that, have the need to do an image field type. Ideally, you could define the subfields with an array of Nova fields such as Text, Textarea, etc.

[kkoppenhaver]

Yes being able to define all types of Nova fields would be ideal, but I haven't dug into the code yet to figure out just how straightforward it would be to modify.

@slovenianGooner If you want to tackle the image field type that would be awesome too! We have to build out the rich text for a client project, so I figured I'd contribute it back if I can get it working.

[slovenianGooner]

Yeah, will get to it over the weekend - I also need to build this for the purpose of creating carousel items - so I need an image field that creates a blob.

Can't promise anything, though :)

[slovenianGooner]

Currently I'm struggling to make the "FormTextField" react to v-model - or am I thinking wrong? Other than that, I see no issues. So display is not an issue, but getting value back from the component, so I can update the value here is the problem. If someone has any inputs on how to do that, would speed this up really.

[fourstacks]

Using the 'normal' nova fields has been suggested before but would be a pretty big departure from the way the package works at present (assuming it's possible to do in a nice way in the first place). To be honest this package was built to tackle an issue I had on one of my own projects and I really just needed something simple. I'm not averse to the idea of a more ambitious approach with more complex fields though it's worth bearing in mind the pros and cons of each approach:

Approach A would be to continue building out fields within the package itself. Largely sticking with the API that the project already has.

Pros: Those fields can be styled to fit in with the way this package styles fields (for example each field can have the move/delete buttons on hover etc

Cons: The more fields (and more complex fields) that get added, the greater the divergence from what Nova does. We're basically reinventing the wheel for each new field type

Approach B would be to try and find some what of using the actual Nova field types themselves

Pros: This would have the benefit of giving access to the full nova field API and all field types. It would also solve a lot of the feature requests since this package was developed.

Cons: Technically this is probably quite complex. I'm also not sure how you'd be able to style those fields so that they can be laid out in the way the package currently lays things out. This would also be a major breaking change - not the end of the world of course but worth considering.

Approach B definitely has it's advantages over A and I'd be stoked if someone wanted to spend the time trying to figure out some of the problems involved in making it work. I'd be happy to help out where I can but I've got a number of other commitments on the go at present so my time is limited.

[slovenianGooner]

As you've said approach B should be the end goal but we would really need to get some insight into how to make it work - I've tried for a couple of hours today and the only sticking point for me is how to get the value back from ie. FormTextField. As far as I know, the "fill" method is called before saving the resource, which means you can't actually rely on the v-model to be reactive - which is where I've failed.

Perhaps someone with a bit more knowledge in Vue and how form fields work in Nova could help out.

[onemoreahmad]

Few weeks ago I tried to implement Nova fields, I had some success with some of the fields but not all of them, I just got busy and stoped working on it, but I think it's possible to do it instead of the plan A because you don't need to reinvent the wheel with every new filed type.

Here is some screenshots, as you may notice, image field doesn't work and the Trix field save the data correctly but not showing it again when updating, still need work and testing though. I'll try to work on it in this weekend hopefully.

Code

When creating :

Database :

When updating :

[fourstacks]

@onemoreahmad Nice work! Do you want to open a PR on a feature branch with what you have so far? I'd be happy to try and help get this over the line as your approach is definitely the one I think this package should take. Clearly, this would be a major breaking change but if we can work out those more complex fields then it solves one of the most common requests for the package (specifically "can you build X field type...")

Thanks for working on this

[onemoreahmad]

@fourstacks Sure! I'll create a new branch and open a PR. Keep in mind that I'm a totally new to all of git/contributions/PRs thing, so I'll just create a new branch on my fork repo and open a PR here and you take it from there 😄

[fourstacks]

@onemoreahmad - don't worry - I'm making it up as I go along too!

[kkoppenhaver]

So for our project, we needed the Trix field to work and I was able to look into this over the weekend.

For the Trix field, at the very least, the method for updating the value (on page load) is slightly different.

Inside SubRowField.vue and inside the mounted() method, if I do something like:

if(component.field){
    component.value = _this.value[component.field.attribute]

    if( component.field.component == 'trix-field' ) {
      component.$children[0].$children[1].$refs.theEditor.innerHTML = _this.value[component.field.attribute];
    }
}

then it seems to set the value properly for the initial page load. The value can then be modified and everything saves normally.

Note that instead of just setting the value, I have to use the innerHTML method provided by the Trix editor. The children offsets are specific to my project and would have to be generalized before this work is merged into the package at large, but this should at least help with the roadblock.

I think something similar may be required to get the image field working, but haven't looked into it as of yet.

[fourstacks]

@kkoppenhaver - thanks for continuing to look into this. I recently came across another Nova package that does what you're trying to achieve. I'd urge you to take a look at this as I think it might be the answer to your problems.

Rather than trying to remake the wheel in this package I'm thinking of directing people to use that flexible content package instead of this one. It's a much more robust solution.

I feel like this repeatable fields package worked well and it's a nice simple solution to a common problem but to be honest I don't have the time spare to give it the attention it needs and if there's a more robust and well-maintained alternative out there then it's probably in everyones interests that time and energy is directed there rather that here.

Thanks again for the time and effort looking into this though - it really is appreciated