I am converting a svelte website to a sapper website. The current routing library had the ability to specify aliases for routes, so in my localized case, mydomain.com/hello-world and mydomain.com/vamos-companeros would be the same route/component, only the language on the page would change. I read this in the docs:
If you want to capture more params, you can create nested folders using the same naming convention: [slug]/[language].
but that unfortunately does not fit my use case. Anybody an idea whether and how this is accomplishable? Thanks in advance.
The way I did it now was to create a common component _component.svelte which would not get used as a route and move all my shared logic there. The components hello-world.svelte and vamos-companeros.svelte would reset title and meta tags and then pass the text for the page to _component.svelte, which renders them together with other shared assets like images.
Related
Any way to prefer pages/hello over pages/[slug] where slug = hello . They're the same route, can Next differentiate between them?
I don't think it is possible. It is specifically mentioned as a caveat of dynamic routes in the doc.
Your predefined /hello will take precedence over dynamic /hello
You have to create pages folder and if you create hello.js and it can be access /hello you can find more info on nextjs doc page
https://nextjs.org/docs/basic-features/pages
Two different client needs their own theme and their respective theme colors are saved in Variables1.scss and Variables2.scss files. On startup, application makes a http call and pulls the information like name of the company. Now, depending on the company name, I want to make decision whether to import Variables1.scss or Variables2.scss.
It seems kind of tricky because compilation of SCSS to generate CSS is done in first place. And only after that application starts up and pulls the company information from database.
Building the application for each client by importing their respective Variables.scss file could be a simple solution, but if the no of company grows, this way would not be feasible.
I went through a lot posts which are kind of related to mine, but they either suggested a solution which creates lot of code duplication or they lead me to change the name of the classes throughout the application.
Suggestions from experts would be highly appreciated.
I believe that the best approach here is to use CSS Variables.
For variables1.scss and variables2.scss you know their structure and which properties they contain, based on that you can create the same properties using CSS Variables and then mapped into your application to a common variable:
e.g
$background-default: var(--background-default)
And when you make the Http request load the variables dynamically based on the response.
When I use the next/link component to link my pages together, I ended up having to specify both the "server side" URL and the queryparam-eterized URL.
An example could be a dynamic /post/:id route that is served by the pages/post.js file:
<Link href="/post?id=2" as="/post/2"><a>Go to post number 2</a></Link>
Is there a different way to do this? It's cumbersome to remember to do this everywhere I want to have a dynamic route.
The href is always necessary as it point to the page that will take care of rendering the content. However the as prop is optional, it's only used to "prettify" the URL shown to the user.
Imagine you land on a site and you see www.mysite.com/post?id=121, looks uglier than just /post/2.
This is still cumbersome, hence there are a few nice libraries that make this easier, the most popular AFAIK is https://www.npmjs.com/package/next-routes, this package makes your life easier when using Link, however you need to write down your own routes.
Based on recommendations for the preparation for Ember 2.0...
• In general, replace views + controllers with components
• Only use controllers at the route level...
...we're supposed to eschew Controllers and Views in favor of Components. I haven't been able to figure out and/or understand how to generate Components that aren't direct parents of the components folder, i.e. components/component-name.js.
My current controllers folder looks something like:
/controllers
/account
index.js
edit.js
/business
index.js
Basically, there are sub-folders that group logic based on the sections of the application. How do I accomplish this with just components?
Seeing that components must have a "-" in them, I tried, but get an error...
ember generate component account/index-module.js
You specified "account/index-module.js", but due to a bug in Handlebars (< 2.0) slashes within components/helpers are not allowed.
Do all components have to be like
components
account-index.js
account-new.js
business-index.js
i.e. all in the same folder? This will start to get out of hand with the addition of what I actually consider to be components (things like video-viewer.js, text-editor.js, radio-button.js).
I would really like to have components in sub-folders, but unsure how to do this.
components
/media
/audio
audio-player.js
/video
video-player.js
/text-editing
text-editor.js
editor-toolbar.js
My components folder is already gross and I just got started:
Is it okay to leave the account/business logic in Controllers (seeing that it does say you should only use controllers at the Route level)?
I'm really confused about this "all components, all the time" convention.
Ok, so I had the same problem and as of ember 1.9-beta.3 (that's the version I tested). It is possible to have components nested under resource directories.
That means that you can have a "user" route or resource. And let's say you have a component which you only want to use with the user resource, so you want to put the component under the resource directory.
The way to do it is to put the component under the resource directory app/pods/user/component-name/template.hbs. The important part is to remember that components must have a dash in their name. It can't be just .../user/component it has to be .../user/component-name with a dash. Then you can use the component as {{user/component-name}} in your templates.
Also I think this is only possible when you're using the pod structure.
Ok, I think this question/answer needs a bit of an update for 2019. I have been using Ember for all of about a month, and my components folder has already become a pigpen. And the tutorial and main API docs don't really cover how to organize your components.
So I did a search of course. And the only answers I could find (like this one) are from around 2014-2015, and don't reflect modern Ember. I was about to accept my fate when I found this in the Ember syntax conversion guide.
(Note to the Ember folks: This is an important issue, one that almost every new user will encounter. It should feature a bit more prominently in the documentation. Maybe not the tutorial, but definitely in Components section)
You can in fact generate components under a sub-folder in Ember as such:
$ ember generate component foo/bar-baz
installing component
create app/components/foo/bar-baz.js
create app/templates/components/foo/bar-baz.hbs
installing component-test
create tests/integration/components/foo/bar-baz-test.js
So that's great, the files are created under components/foo and templates/components/foo. And to resolve the name of the component for use in another template, you can use either the old style syntax:
{{foo/bar-baz }}
Or the new style angle bracket syntax:
<Foo::BarBaz />
As the assertion suggests this is due to Handlebars 1.x, and will be available soon.
Ember 1.9 beta builds currently support this, though I'm not positive if ember-cli's resolver would work with it right now. You can read more about Handlebars 2.0 here.
Using a pods structure will also help with organization, and I believe is going to be the recommended strategy going forward.
For now, I'd suggest not to worry about it! Remember the transition plan will be smooth, and as the official releases come out for Ember and Ember CLI, you'll get deprecation warnings.
I am attempting to place multiple controllers within my template partials with AngularJS- The problem I am encountering is that of the first layer, direct-linking to these sub-controllers and their related snippets.
An example would be a management page for user accounts, say I am on a user-list and wanted to change a user from the list's password, I click on their change-password button, and want to redirect the user to #/ManageUsers/ChangePassword/?UserID=<uid here> rather than #/ManageUsers_ChangePassword/ or similar, but the Angular documentation (Or lack thereof) on the subject suggests that this is impossible, or not 'The Angular Way'...
Being that my team wants to keep these separate controllers as partials, is there a non-hacky way to do this with Angular?
There has been recently published a blog post about one possible way of solving deep linking with AngularJS. It has a parent/child style of implementation where parent sections do not need to be updated if you need to change only contents of the child, which makes it pretty neat.
It's here: http://www.bennadel.com/blog/2441-Nested-Views-Routing-And-Deep-Linking-With-AngularJS.htm
why not direct to #/ManageUsers/ChangePassword/:UserID ? You can get the UserID from $routeParams. See an example on the $route page.
You can even create routes like #/ManageUsers/:OrganizationID/:SectorId/:UserID/ChangePassword/Confirmation that will be used by the url #/ManageUsers/10/2/32/ChangePassword/Confirmation