Open sarathkumarbaskaran opened 6 years ago
Hi, could you provide a reproducible test for this, either in repository form or ember twiddle form so I can help with this?
This is related to https://github.com/ronco/ember-cli-head/issues/23.
Latest version doesn't give the error above, but it also still doesn't work. Fails silently it seems.
Okay so instructions on getting this working on 4.0.0 with an engine.
add ember-page-title
to the engines package.json
"dependencies": {
"ember-cli-htmlbars": "*",
"ember-cli-babel": "*",
"ember-page-title": "*"
},
add headData
to the engine.js
services dependencies
const Eng = Engine.extend({
modulePrefix,
Resolver,
dependencies: {
services: [
'headData',
],
},
});
add headData
to the app.js
engines dependencies
const App = Ember.Application.extend({
modulePrefix: config.modulePrefix,
Resolver,
engines: {
account: {
dependencies: {
services: [
'headData',
],
},
},
},
...
I think you now also need to override head.hbs
. I'm not sure but worth a try to do it as mentioned in the docs. I couldn't get this working without overriding it in general.
app/templates/head.hbs
<title>{{model.title}}</title>
What I posted doesn't fully work. It works on fresh loads on any page. But only for the initial engine/app. So if you load an app route it works there only, all engines it won't. Or if you load into an engine then it doesn't work in app or any other engine.
😭
Engines are just a mess anyway.
This worked for me: ember-page-title: 4.0.2
. (Only tested with one engine)
1) add ember-page-title to the engines package.json
"dependencies": {
"ember-page-title": "*"
},
2) Create head.hbs
file in ${engine-name}/addon/templates
<title>{{model.title}}</title>
3) add to ${engine-name}/addon/templates/application.hbs
{{head-layout}}
I did this change but I still have the issue of going in or out of an engine it doesn't work. What happens is the first loaded part (if app or engine) gets the page titles working but if you go to anything else it stops (going back works in the original area).
Could someone create an engine test PR so we can work on getting this resolved?
I refactored away from engines and life has been easier, so this issue doesn't concern me anymore and I don't suggest anyone use engines at all. I'm gonna unwatch this.
This is still an issue for me, since I have quite a big web app that I had to split with engines. Just to let you know. I'll try and look into the code when I have time. P.S. Engines are here to stay as far as I know, so I'm afraid this bug will have to be solved eventually... even though I realize it's a pain in the butt.
@danidr we have a very big app, and using engines was a very bad decision (by me). Most problems they solve are being solved in other ways with ember octane. And it barely has development on them. So I recommend noone use them at all. I can share the script that I made to convert back into app if anyone wants it.
I'm confident you will continue to run into other issues are ember updates happen etc if you use engines (in-repo ones anyway, the out of repo ones that are more standalone I think are still mostly okay).
@robclancy Sure, my comment was not directed towards you; let's say that besides some little things that needed to be worked around, engines are working fine for me, and as far as I understand, this is the way Ember is going for asynchronous loading of components/routes. In the current state, I see how it can be a headache for really complex apps, if they need more than 2-3 engines overall. I guess we'll see what the future of engines will be; I decided to go this way because it was a little more supported by the community and we were in dire need of separating some parts of the app logically (to be reused, instead of creating an add-on).
and as far as I understand, this is the way Ember is going for asynchronous loading of components/routes.
Nope or engines would have been improved a lot more by now if they were using it as the solution to how big the app can get. Code splitting is what will be used here https://www.emberjs.com/statusboard/
Then organizing code will be improved with module unification (other reason I used engines at first).
@robclancy Very interesting read, thanks. Well, each part has its role there. Please notice that
Engines is mostly production ready, and is used by major companies such as Chase and LinkedIn.
in that same article you have posted.
Engines may not be the best choice if the only concern is asynchronous loading, and I think their use case is very specific. They are conceptually add-ons that can also be asynchronously loaded, and their most interesting feature is probably strict code separation.
Bottom line is: I respect your point of view, and I too hope that engines will be reorganized (and possibly eliminated with module unification), but for now, it is a (albeit imperfect) way of solving a problem, and as such, I do hope that ember-page-title
will support routed engines.
Going back to the topic, being this a shared service, the behavior is strange. I'll try to see if I can contribute by finding some more information about the bug!
Yes and after using it for 11 engines and seeing all the problems in discord over and over I don't think they should be recommended at all. I actually think it should be deprecated.
I've managed to make ember-page-title works with ember-engines@0.8.5, following these steps:
'head-data'
and 'page-title-list'
as dependent services in both the host app and the engine.Would be awesome to get a pr for the readme @nightire
With v6, should no longer need the head-data service, since we no longer use ember-cli-head.
As @knownasilya mentioned, with v6 only "page-title-list" service is required.
However we can definitely improve documentation for Ember Engine setup.
@raido, what does the modified config look like for the engine addon? Can you provide a sample? For package.json
of the engine addon, right?
I'll try to test this out and come up with documentation PR.
AFAICT the only steps needed are:
ember-page-title
as a direct dependency (needed to have the page-title
helper available)page-title-list
service to make sure it uses the same instance as the hostStep 2 might be a little weird as I don't think we consider the page-title-list
service as public.
We could also link to the ember-engines
documentation for additional info on service dependencies:
https://ember-engines.com/docs/services
I'm running Ember 3.28 and ember-engines 0.9.0 (latest version of engines available), and I have noticed that the page title in an engine seems to display properly when the app loaded on a specific URL, but if you browse in the engine to another route the page title is reset to the Ember default -- if you reload again on this new engine route the proper title will then display.
I'm just using ember-page-title
as a dependency on the engine and not referencing page-title-list
anywhere.
Is this a known issue?
Stack trace