Is it possible to add more scss variables with default value in order to customize:

• the background-color of the bar (#eeeeee => $as-background)
• the images in the center of the bar (url('data:image/png;base64,...') => $as-horizontal-icon)

Or to use css variable, it can also work :)

Is it possible to add more scss variables with default value in order to customize:

• the background-color of the bar (#eeeeee => $as-background)
• the images in the center of the bar (url('data:image/png;base64,...') => $as-horizontal-icon)

Or to use css variable, it can also work :)

That's unrelated to this PR and already got merged in #367

@SanderElias @Jefiozie the merge conflicts are only due to CSS variables PR.
You can still go over this one even though there are merge conflicts which I will solve only next week unfortunately.

Anxious to see this new version. I was in the process of updating my dashboard app to try and include cdk drag & drop. I'll not waist time and wait a bit so I'll be available as a beta tester if needed.

Thanks for all the great work you are doing!!!

I currently use [order] on split areas that are included/excluded from the dom with an @if/ngIf. Without setting the order, the areas included by the @if/ngIf always get rendered after the static area(s). Would this PR break this functionality?

Example:

<as-split
  direction="horizontal"
  unit="percent"
  [gutterSize]="8"
>
  @if (currentHelp()) {
    <as-split-area class="tt-help-split-area" [order]="0">
      ...
    </as-split-area>
  }
  <as-split-area size="*" [order]="1"><ng-content></ng-content></as-split-area>
</as-split>

I currently use [order] on split areas that are included/excluded from the dom with an @if/ngIf. Without setting the order, the areas included by the @if/ngIf always get rendered after the static area(s). Would this PR break this functionality?

Example:

<as-split
  direction="horizontal"
  unit="percent"
  [gutterSize]="8"
>
  @if (currentHelp()) {
    <as-split-area class="tt-help-split-area" [order]="0">
      ...
    </as-split-area>
  }
  <as-split-area size="*" [order]="1"><ng-content></ng-content></as-split-area>
</as-split>

With this PR the order is based on DOM order. That means if the ngIf adds the area before the static ones it will work as expected.

@Jefiozie Would you have time to review this?
This would be a breaking version, but it takes care of quite some things we have on our list. I did review it lightly, but currently don't have time to go in deeper.
I'm ok with the changes, have discussed most of my concerns with @Harpush , and I think he has addressed those.

I left some questions but nothing serious. My main concern is that I would like to have a deprecation notice before we remove the old types OR we need to have a schematic in place to migrate everything.

Im not against either one but backwars compatibily is something i would appriciate.

@Jefiozie Concerning deprecation and migrations - let's review what needs discussion:

1. expand/collapse feature - Should I add it back as it was but deprecated? Should we replace it with some kind of snap feature like vscode? Maybe delete altogether (breaking)?
2. getVisibleAreaSizes/setVisibleAreaSizes - What do we want to do about those? Deprecate maybe? Delete (breaking)?
3. Order input - Not needed anymore so we can either migrate or deprecate. I don't really think we want to keep supporting it. The problem is when someone used it not in the same order as the DOM.
4. split-area used as directive can be migrated with schematics. Deprecation isn't possible here.
5. ANGULAR_SPLIT_DEFAULT_OPTIONS can be deprecated or migrated.
6. component TS reference input changing - nothing we can really do about it... that's just not supported anymore with signal inputs.
7. Interface names - either migrate or export old names as type aliases of new names with deprecation.

If we go the schematics direction - we need to create the required infra as there is no schematics collection project in this repo.

When will this be available?

@Jefiozie I wrote some considerations above - can you share your opinion on them?

@Harpush I actually am using the collapse/expand for snapping like in the vscode. Can you please maybe add a snap option? I had to sortof implement it with the collapse/expand feature. Don't remove it please.

@Harpush I actually am using the collapse/expand for snapping like in the vscode. Can you please maybe add a snap option? I had to sortof implement it with the collapse/expand feature. Don't remove it please.

Can you please elaborate how you would expect the snap to work? Visible vs @if and size restoration.
The main reason why collapse seemed like a weird feature to me is the ability to collapse to non zero values. A snap feature is indeed expected from a split component imo.

Is this great upgrade planned to be available soon? Can't wait to try it out!

@Harpush we've decided to leave it as is and merge it. We will do a beta release of the package soon.

@Jefiozie I wrote some considerations above - can you share your opinion on them?

In that case how about an RFC on a snap feature to replace expand/collapse?

That is a good idea, would you be interested in writing the first draft/ iteration?

That is a good idea, would you be interested in writing the first draft/ iteration?

Sure I have something in mind that should also answer most of the collapse/expand intended usage hopefully.
I just need guidance as to where to send you the draft or should I publish it as a GitHub issue directly?

Hi everyone,

We just released a beta version of angular-split, you can find it angular-split 18.0.0-beta.0

@Harpush How can I programmatically change the sizes? Without using the mouse. What should I use instead of collapse/expand/
I used them to have something like the vscode splitter. I can resize the sections and also click ob the headers and the collapse/expand.

@Harpush How can I programmatically change the sizes? Without using the mouse. What should I use instead of collapse/expand/ I used them to have something like the vscode splitter. I can resize the sections and also click ob the headers and the collapse/expand.

Option 1: like the custom gutter demo use hide or @if or size 0.
Option 2: vote for the RFC #458 :)

@Harpush Why did you change SplitArea from Directive to a Component? For me, this is a breaking change, and I don't see why it was done. It does break CSS when you force main elements to be constrained to the screen size. I do have to use a lot of 100dvh, and every additional div in the path from the body to the last non-scrolling element is another possible breaking element in the chain.

I was asked to make a PR, but before doing anything, I want to know the rationale.

@Akxe split area has both css and html template. It also affects the host styles and classes. Making it a directive will require to use DOM apis to emulate html and css.
Also if you ever put that directive on your component directly the directive will affect your component host styles and add an element inside it.
That means a general recommendation is to use a div for example around your component which essentialy is the same as an area component.

If you think adding the directive to your component will work and won't break anything you can create a PR that changes the split area component selector to support attribute selector while keeping it a component.
I think though this isn't recommended and should be an advanced case and the docs should reflect the dangers.