嵌套修饰符 ng-repeats 不尊重 $index?

Nested modifier ng-repeats do not respect $index?

我最近尝试了 famo.us 和 angular。我喜欢它,但我在让 sidenav 按我想要的方式工作时遇到问题。

当我单击任何 Test1-3 菜单项时,我希望 child 菜单项从其下方滑动打开。我还没有实现任何滑动,因为我目前的问题是没有 children 似乎尊重布局的 fa-index。

更新: children 加载和卸载都很好,只是它们总是出现在菜单项的底部,而不是在它们下面。我对 fa-modify 标签做错了吗?如果我在 angular 工作,我很确定我的 ng-repeats 会按预期使用此设置工作。

                <fa-app>
                    @*<fa-grid-layout fa-options="myGridLayoutOptions">*@
                    <fa-sequential-layout fa-options="navCtrl.sequentialOptions">
                        <fa-modifier ng-repeat="item in admin" fa-size="[true, true]" @*fa-size="[true, undefined]"*@ @*fa-proportions="[1, 1]"*@>
                            <fa-surface>
                                <md-list-item ng-click="navCtrl.toggleMenuExpand($index)" @*ng-click="go(item.link)"*@>
                                    <a>
                                        <md-item-content md-ink-ripple layout="row">
                                            <div class="inset">
                                                <ng-md-icon icon="{{item.icon}}"></ng-md-icon>
                                            </div>
                                            <div class="inset">
                                                {{item.title + " " + $index}}
                                            </div>
                                        </md-item-content>
                                    </a>
                                </md-list-item>
                            </fa-surface>

                            <fa-modifier ng-if="item.active" ng-repeat="submenuItem in item.submenu">
                                <fa-surface fa-index="1">
                                    <md-list-item ng-click="go(submenuItem.link)">
                                        <a>
                                            <md-item-content md-ink-ripple layout="row">
                                                <div class="inset">
                                                    <ng-md-icon icon="{{submenuItem.icon}}"></ng-md-icon>
                                                </div>
                                                <div class="inset">
                                                    {{submenuItem.title + " " + $index}}
                                                </div>
                                            </md-item-content>
                                        </a>
                                    </md-list-item>
                                </fa-surface>
                            </fa-modifier>
                        </fa-modifier>
                    </fa-sequential-layout>
                    @*</fa-grid-layout>*@
                </fa-app>

我怎样才能正确地使任何 children 正确显示在每个菜单项的下方?

这里是每个菜单项的数组,只是为了说明。

var adminmenus = [
{
    link: '/overview',
    title: 'Test1',
    icon: 'settings',
    active: true,
    submenu: [{ link: '/overview', title: 'Test1SubTest1', icon: 'settings', active: false }]
},
{
    link: '/overview',
    title: 'Test2',
    icon: 'settings',
    active: false,
    submenu: [{ link: '/overview', title: 'Test2SubTest1', icon: 'settings', active: false }]
},
{
    link: '/handover',
    title: 'Test3',
    icon: 'attach_money',
    active: false,
    submenu: [{ link: '/overview', title: 'Test3SubTest1', icon: 'settings', active: false }]
}
];

更新: 我是否以错误的方式看待 famo.us 实施?我看到 this answer,想知道我是否应该从控制器生成带有适当子菜单的菜单..

长话短说,这个功能很可能没有在 famous/angular 集成中实现。

我将放弃这次尝试,因为 famo.us 正在对他们的引擎进行重大返工,而 famous/angular 则被遗弃。对于任何阅读者,我建议在他们的新引擎开发得足够好时再次查看 famo.us 和 angular。

This (somewhat hidden) announcement 来自 famo.us.

的 Zack Brown

The future of Famo.us/Angular

I can give some insight in the future of Famous in relation to AngularJS, and the path we've taken to arriving at this decision.

Famo.us/Angular is an integration library. Its roots extend deeply into both of the integrated libraries (Famo.us 0.3 and Angular 1.x) and its implementation is very specific to the idiosyncrasies of those two libraries. Some example integrations:

patching into Angular's animation and lifecycle system to trigger and handle Famo.us animations patching into Angular's directive compilation system to build the Famo.us render tree in the first place creating directives that allow Famo.us event piping into the underlying Famo.us render nodes supporting Angular's event pipeline (e.g. ng-click on top of Famo.us Surfaces) supporting ng-repeating elements into a Famo.us Scrollview or GridLayout handling cases like ng-show and ng-if in Famo.us making the whole thing perform well within the constraints of Angular's digest cycle. etc. And these are just a few of the many adventures that we encountered while building Famo.us/Angular. Now let's bring four different libraries into the mix:

Famo.us 0.3 Famous Engine, a.k.a. "mixed mode," a.k.a. 0.5.0 Angular 1.x Angular 2 To fully support integrations between {Famo.us 0.3, Famous Engine}x{Angular 1.x, Angular 2} would require four completely distinct integration libraries. Obviously, this isn't tenable.

Famo.us 0.3 is deprecated. Thus, we can rule out integrating it with Angular 2. The question then becomes: should we write an integration between Engine and Angular 1.x, or Engine and Angular 2, or both? While we're at it, should we build an integration with React? With Ember? With Backbone? Mithril? FOAM? Insert-JavaScript-Framework-Du-Jour?

The answer is, we absolutely plan to support all of these, but we don't want to (and can't afford to) write a from-the-ground-up integration with all of them.

So what's the trick?

If we do our job right, no one will have to write a heavy-weight integration like this again.

We (at Famous) have to write "one integration to support them all" — we don't want to integrate Famous Engine with AngularJS; we want to integrate Famous Engine with web authoring standards in such a way that using Famous with, say, Angular or React—or even just Bootstrap—is simple. The good news: we're already writing it. It's our Framework Layer. (oh, and that's why Engine is called Engine—it's one of two layers of the Famous Project: Engine and Framework.)

What does this Framework look like?

It supports HTML as an authoring language. This is key, as it allows mixing in other applications/frameworks both inside and outside of the Famous render tree.

It exposes very clear, simple-to-use interfaces for manipulating Famous components. This allows for logic from any other application/framework to interact with Famous in a consistent, predictable, and extensible way.

It supports passing through to raw Famous Engine anywhere it's needed.

It supports passing into and out of Famous or HTML flexibly, and allows easily working with CSS and other assets (images, fonts, other media.)

In other words: writing an Angular integration with the Framework will be loads simpler than writing it with straight-up Engine. I strongly encourage anyone who's interested in an Angular<>Famous integration to wait for the rest of Famous, i.e. the Framework, to be released.

When is that?

As of now (June 2015) Framework is still in Private Beta. We are inviting anyone who's interested and who can make it to come on site in SF to work with us in Famous Labs to test-drive the Framework and get/give feedback directly with the Framework team.

We will be making an announcement about Framework at jQuerySF toward the end of June. It's very possible we will release our Public Beta on that date.

You can reach me at zack@famo.us if you're interested in the Private Beta or more information.