Adding a class only to the snapped slide

[jln13x]

Hey there,

first of all: Embla is amazing, thanks for your work!

I constantly ran into the requirement to only style the currently snapped slide (usually the one in the center) and the plugin embla-carousel-class-names couldn't help with that. The closest option would be the selected one however that applies to all visible slides which is not something that I want.

Use Case:

So I went ahead and quickly wrote a plugin for it and published it to npm to reuse it across multiple projects. The plugin basically just adds a class and allows me to style it.

Would that be something for the embla-carousel-class-names-Plugin ?
If so, I would go ahead and contribute to it and delete my stuff.

If not, is it ok for me to keep the plugin published? Anything I should add?

Thanks alot!

[davidjerleke]

Hi @jln13x,

Thank you for your question.

Would that be something for the embla-carousel-class-names-Plugin?

In most cases your approach will work. But there are setups that makes things a bit more complicated. Especially these two options:

• slidesToScroll when set to anything else other than 1.
• containScroll when set to trimSnaps.

The reason for this is that they will group slides and reduce the number of snaps. As a result, the number of snaps will be less than the number of slides. How should we tackle that?

Example:

Slides are 25% wide so 4 slides fit within the viewport at the same time. slidesToScroll is set to 2, so slide 1 and 2 are one group (behaving as a single slide and share the same snap), and slide 3 and 4 are one group and so on...

Let me know if you have any ideas.

Best,
David

[jln13x]

Hey David,
came up with a solution.

jln13x/embla-carousel-snap-class@177b568

Let me know what you think of this approach. Just checking the options for the slidesToScrolll option and then calculating which nodes belong to that snap group.

[davidjerleke]

@jln13x thanks for the suggestion.

I think Embla should expose the scroll snap groups with embla.internalEngine() because Embla already has that information internally. It's good to have one source of truth and the upcoming embla-carousel-fade also needs access to the same information. Another benefit of doing it this way is that we don't need to duplicate the logic.

Assuming the property is named groupedSnapIndexes, a part of the implementation would look like this:

const slides = embla.slideNodes()
const { groupedSnapIndexes } = embla.internalEngine()

function addClass() {
  const activeSlides = groupedSnapIndexes.map(groupedIndexes => groupedIndexes.map(index => slides[index]))
  activeSlides.forEach(addActiveClass)
}

Note that at the time of writing, the groupedSnapIndexes property is imaginary. I haven't added it yet. I think it would be nice to add this to the existing embla-carousel-class-names plugin. For example, we can add an option so users can decide if the plugin should add the selected class to slides:

• That are in view (the current implementation).
• Or based on the current snap/snap group.

What's your thoughts about this approach?

Best,
David

[jln13x]

@davidjerleke I like the idea of exposing this logic from embla.internalEngine().

We can also additionally expose the scroll snap groups as HTML Element array so we abstract the logic abit.

const { groupedSnapElements }  = embla.internalEngine()
groupedSnapElements.forEach(addActiveClass)

Letting the users decide between where to add the classes seems possible.

However I would like to suggest that we change the name and description of the selected option (current implementation).
It was abit confusing for me in the beginning because I actually assumed that selected would actually mean "snapped" rather than "in view".

Suggestions:

• Rename selected to in-view
• Add new option snapped OR keep using the name selected for it

Best,
Julian

[davidjerleke]

Hi Julian (@jln13x),

However I would like to suggest that we change the name and description of the selected option (current implementation).
It was abit confusing for me in the beginning because I actually assumed that selected would actually mean "snapped" rather than "in view".

Suggestions:

• Rename selected to in-view
• Add new option snapped OR keep using the name selected for it

Thank you for your feedback. It's valuable for me because I can't know if the naming makes sense to users or not unless they say something. So much appreciated.

I'm not sure that I understand you correctly. Is this what you're suggesting?

const options = {
  inView: 'in-view-class-name',
  snapped: 'snapped-class-name'  
}

If yes, I think this will cause confusion because I'm thinking that they should be mutually exclusive, meaning that you can only have one or the other.

If no, please let me know what you meant.

Cheers,
David

[jln13x]

Yes that is what I was suggesting.

Could you please further explain why do you think that this would cause confusion? Is it because of the naming?

I am not so sure about the option being mutually exclusive because there are use cases where you would want to style the snapped slide different compared to the other slides in view (as seen in my example)

Greetings from Germany 👍

[davidjerleke]

Hi again Julian (@jln13x),

Thanks for clarifying. I see. Well I guess they don’t have to be mutually exclusive. I agree that the feature you’re suggesting would be a nice addition, but when introducing this feature we initially have to limit ourselves to this:

• We can’t rename selected class to inView until the next major version release of Embla because it’s a breaking change. So for now, we have to stick with the selected name for slides in view.

Best,
David

[jln13x]

Hey there David,

Yes, as you said, we should not rename the selected option until the next major. However maybe we can introduce the new option inView already and mark the selected option as deprecated (to be removed in the next major).

Other than that, planning the next steps: You mentioned earlier that another plugin embla-carousel-fade would need access to similar data. Did you prepare something already or are you going to? Otherwise I would go ahead and tackle it after further laying out the necessary requirements.

[davidjerleke]

Hi @jln13x,

as you said, we should not rename the selected option until the next major. However maybe we can introduce the new option inView already and mark the selected option as deprecated (to be removed in the next major).

That was actually what I was suggesting but I realized that it was all in my head and that I wasn't clear on this. Thanks for writing this 🙂.

Other than that, planning the next steps: You mentioned earlier that another plugin embla-carousel-fade would need access to similar data. Did you prepare something already or are you going to? Otherwise I would go ahead and tackle it after further laying out the necessary requirements.

At the time of writing, I haven't made these changes but I have a clear picture of what needs to be done. I think it's good if I prepare exposing the information needed for the existing embla-carousel-class-names and future embla-carousel-class-fade plugin, because I know all cases that needs to be covered. I will create an issue, a branch and a pull request that we can work on together. I can't give an ETA and make promises about when (because I have two kids and the oldest is 3 years old so I have pretty crazy days), but I'll do my best to get it done as soon as possible.

But as soon as I'm done with exposing the information, I'm suggesting that you add the inView feature to the existing embla-carousel-class-names plugin, assuming that you wouldn't mind doing this?

Best,
David

[jln13x]

Sounds like a plan! Thats how we are gonna do it, looking forward

[davidjerleke]

@jln13x this feature has been released with v8.0.0-rc12.