Confused about which features are Octane only

Hello all,

I’m starting a fresh project (Ember 3.14.1) and I’ve enabled some optional features but I’ve decided to forgo enabling Octane for now. My question is what features are Octane only at this point? My confusion lies with blogs that say things like “Octane preview: Angle Bracket Components” or “tracked properties” etc. I’m using some of those features right now in my new project without having enabled Octane. Is there a way for me to determine what’s actually “siloed” in Octane so I know which features to use?

Appreciate it!

You could optionally start using octane since 3.13. octane is feature complete, and you can use it in its entirety :+1:

Since Octane is the first time we’ve done an “edition”, it can be a little confusing.

There are no features that are “octane-only”. All the features in Octane work in at least one stable Ember release, and many of them have been stable for a many releases. They’re safe to use in any app.

Editions are trying to help us balance two needs:

  • it’s better to improve software in small incremental steps, rather than giant releases
  • but it’s easier to learn new things once all the new pieces are ready, rather than learning only some of the pieces and dealing with a half-new way of thinking.

People who want to pick up any new feature in isolation are encouraged to do so. While people who don’t want to be distracted by new things can wait until an “edition” is announced saying that a new coherent set of features is ready for broad adoption.

“Turning on octane” doesn’t actually enable any features. It does things like change the default blueprints so that when you generate a new component, etc, it will be formatted in the new octane way.

So the difference between “pre-octane” and “octane” is not really about what things work. It’s about what things a person needs to learn to use Ember. So the choice of when to start using the octane features is mostly about when your team is ready to spend some time learning.

1 Like

Thank you. I honestly didn’t know that. I’ve been “waiting” but now I learn If my version is high enough I can use octane-ish features without feature flags?! Yes!.

1 Like

Thanks for explaining that to me. I think I understand it more now. If I understand correctly there’s just certain coding idioms and syntax only usable if your app is built using the Octane preview. I.e. @tracked properties decorator being one VS I can build my components right now using native Javascript class syntax? Am I thinking of it in a more correct sense?

Thanks again :slight_smile:

Does this include the directory structure? Is that going to change in Octane? If so, will there be a codemod for that? (Not sure if something that complex could be done, but figure it doesn’t hurt to ask.)

Yes, octane includes Component Template Co-location. And yes, there’s a codemod.

It’s not a huge difference to the directory structure, but it’s by far the most requested one. Example:

Old way:

app
├── components
│   ├── just-class.js
│   ├── my-widget.js
│   ├── nested
│   │   └── another-widget.js
│   └── ...
├── templates
│   ├── components
│   │   ├── just-template.hbs
│   │   ├── my-widget.hbs
│   │   ├── nested
│   │   │   └── another-widget.hbs
│   │   └── ...
└── ...

New way:

app
├── components
│   ├── just-class.js
│   ├── just-template.hbs
│   ├── my-widget.hbs
│   ├── my-widget.js
│   ├── nested
│   │   ├── another-widget.hbs
│   │   └── another-widget.js
│   └── ...
└── ...

Things other than components (services, routes, route templates) remain the same in Octane.

My favorite is the componentStructure: nested, because then you can do:

app/components/foo/{index.js,index.hbs,-page.js,etc}

Great news! Thanks for the instructive feedback.

Isn’t this already available with pods?

Pods is a little bit different - there is a folder for each component containing a template.hbs and a component.js file. Pods can get a little bit confusing if you have 10 template.hbs files open :wink:.

1 Like