I have a CMS based website where I need to add a standalone AngularJS based app. Given the single minified JS for the app is 13Mbs.
The options that I see are:
A.) EMBED the app directly in a webpage, we can add a SECTION/DIV on a webpage and let the script render the app in that tag. With this approach, my concerns are the additional HTTP request and the obvious 13Mbs of additional data.
B.) The other way is to add this app using an iframe and pass the URL, this is the straightforward way. I will not have to retouch the CSS as well. This approach helps in eliminating the above concerns. But I will have to write additional manage the height of iframe to make sure the app looks like a part of the page itself.
Your SUGGESTION, please.
Ask the team to reduce the file size of your javascript or break it into multiple pieces based on nature of your application.
If the libraries inside the application ( JS/CSS) are non conflicting - (which is not the usual case) opt for embeding, because it would give a seamless integration.
If you want to make sure your pages are safe and the application is from third party where you dont have control, put that in an iframe. Ask the third party to talk to your javascript by post messaging, so that you can resize it as and when required. Refer (https://medium.com/#Farzad_YZ/cross-domain-iframe-parent-communication-403912fff692)
Related
The current project is a Single page application developed in Vue. As of now, the content is pretty much static but some data is available via REST APIs.
Now the ask that came up is to maintain the uniformity in terms of design, utilize the Header & Footer menu ( along with HTML & CSS structure) as-is in SPA from Drupal which serves static pages of the other app. There is no correlation between these two web apps.
I have read articles on headless CMS on how they serve the content to the frontend, but since this is a SPA and not Server-side driven, keen to know how to make this happen.
Of course, exposing via REST is an option but it will not be a great UX.
Kindly let me know your views on how to approach this better or what are various options that can be thought of.
Robin
You'll have to hit endpoint at some point from your Vue app.
Either compile regularly the application and consume it as part of the build process so it's static and bundled or make it dynamic by consuming the endpoint via JS.
So there are multiple solutions I can think of,
Make an SSR Node js script which will generate the header & footer and place it in index.html placeholder as a part of the build script.
( Downside is: - Frequent production update based on the changes in Drupal end. )
Make SPA as Server-side render and Respond with updated index.html.
Have an endpoint that will give the menu content assuming the common HTML structure at Drupal & SPA app.
Please let me know if there is a better approach to this.
Thanks
I am currently working on a news website using react js (backend expres.js rest API). This site needs social share functionality with the image and title of the post. I add meta tags using a helmet. I tried to pre-render packages too, Even though this does not show images of the post when sharing. Can I achieve this using API without server-side rendering? please help me to do this.
As far as I know, while you can change meta tags with javascript (see the answers to this question most consumers of meta tags (Facebook, Twitter, etc) request the document from the server, but don't execute any javascript on that page. That way, the scraper consumes less resources, and reduces the number of attack vectors. That means you will need some way to return specific dynamic values in the <head> for different URLs from a server. SSR is probably the best way to do that – at this point, there should be enough different tools/options that it shouldn't be too hard, and you don't need to run two different systems to render markup, one server-side, the way you would if you did something like dynamically alter the contents of your index page.
I did this using next.js (the react framework). This can make API call and generate HTML in the server. With this, SEO and sharing with title and image are working properly.
I developed a Shopify application that i install on Shopify Store and i want my application to add a javascript snippet in all the store pages. For this I want my application to modify the current theme, by using Shopify API, and add the javascript snippet to that theme.
I know of several ways to do it but they have several disadvantage:
Add a Shopify Asset/Snippet - The store owner has to manually modify the store's theme to link to the asset/snippet.
Add a script tag - I want my javascript to be embedded and not to be downloaded from a different source. A different source means longer page loads and i do not want my site to extend the page load.
Add an application proxy - This can also extend the loading time.
Can you suggest on what is the correct way to do it?
Add a script tag and be done with it. No other pattern offers up the same customer experience. When they install your App, your script is available. When they uninstall your App, their theme reverts nicely. Worrying about the load times of your asset is not worth it if you have done your job, and minimized your code and provided a fast CDN address for it.
In 2022, you get Theme App Extensions for OS 2.0. Do that!! Best way to add JS to a theme/store.
Are you using the embedded apps SDK? I'm pretty sure they have some option that makes this easier, like you can create a "sidebar" on every page and position it wherever you want (hidden if necessary).
Answering you question: the good way is using ScriptTag. Consider this article on this: https://docs.shopify.com/api/unlinked/using-javascript-responsibly
Still if you need to add code snippet as an asset, I want to point out that it's not necessary the customer must manually update the theme. As far as I know, you can add your snippet as an asset and then update another -- theme liquid template.
https://docs.shopify.com/api/asset#update
For the reasons described in an article I've provided above, you should not do that.
I want to rebuild an old website made on plain HTML and add some extra functionality with AngulaJS. But since I plan to use ng-views to render templates on my main layout, is it possible to make search engines still find the templates of these subpages?
In a general sense, this is not an angular problem - its the same problem with any single page site that uses javascript to generate your html.
The general solution would be to detect when it is a crawler accessing your page instead of a person (usually by using the query agent string), and then use server side logic to render pages that are suitable for the crawler to process.
Here is one article that discusses this problem:
http://www.webdesignerdepot.com/2013/10/how-to-optimize-single-page-sites-for-search-engines/
but google (or searching this site) for "google seo single page app" will give you lots of other ideas.
Is there a way to have a blog directly integrated into my HTML/javascript-only website, without having to have something like a SQL-database and a dynamic engine like PHP or MySQL?
Maybe there is some service in the web that offers this (hopefully without ads :) ). Or maybe I can have a blog engine entirely written in javasript?
Entirely written in JavaScript? Surely that defeats the entire point of having a "blog-engine" in the first place? The point being that the data is stored somewhere and dynamically retrieved. To avoid using anything server-side (which seems to be your intent), and only use HTML/JavaScript, you'd have to store all the data for the blog in files that are served up to each visitor, and then retrieve the data from the particular, local, locations using JavaScript.
Sorry if I'm misunderstanding the point here... but this seems to be an utterly useless way of trying to go about things. Blogs are, in general, either written statically (in HTML [even though this is rare]), or are dynamically generated from a database by a server-side scripting language (most common).
Edit: As an additional point, I suppose you could include some third-party blog feed, or service, in your page, via use of JavaScript... but I'm unsure as to which (if any) blogging services would directly support this method of working. Additionally, this is quite an unreliable way of including third-party data in a page...
Here's a thought. It's not really a blog engine - but a wiki.
Entirely javascript/html/css. All lives in a single html file:
http://www.tiddlywiki.com/
not sure how it would work on a real live site, but their site is using it:
* A personal notebook
* A GTD ("Getting Things Done") productivity tool
* A collaboration tool
* For building websites (this site is a TiddlyWiki file!)
* For rapid prototyping
* ...and much more!
You could use github pages. You will get a generated blog with version control.
Other option is to use a Desktop blog tool and then update your site.
You can user iWeb if you have a Mac or CityDesk on Windows or you may try this open source tool
Edit Today I came across this tool: Zeta producer that may help.
http://code.google.com/p/showdown-blog/
Blog engine written in just JS and XML [v0.6] {JavaScript, XML}
So, what you want is to have a blog where you're website provider doesn't provide a way to serve dynamic content?
The only way I see that you can do it in that case is writing html-files (or text-files if you prefer) and adding them to the site. After that you can have some JavaScript to add them to your "blog-page".
You of course need to upload them to the website in the same way as you do for the other files, and then have a way for the JavaScript to know which pages it should fetch.
I am not aware of any JavaScript blog-engines, but you can have a look at the templating functions in for instance Prototype
Of course, that means that you will have to fetch both the template and the content through Ajax and let the client do all the processing (could be slow and possibly insecure), and you still need to have a place to upload the content and update it.
Your best bet is going to be using a generator to create the HTML/CSS/JS to upload to your server, take a look at Webby: http://webby.rubyforge.org/
IF you really need to you can use a public api for a service that lets you post small bits of info and retrieve it using javascript.
for example if you only need small posts you can make a blog in html.javascript that utilizes twitter as the engine. of course you will be limited to 140 chars. I am sure there are other services that will allow a similar idea but with less restrictions.
And of course the best option - Get a blog software or host your blog with a service provider and link to it from you site.
Good luck
One solution would be to use some application that generates the static web pages of your blog, and uploads them to your web server. This way you'd have a blog with static content that could all be managed in javascript alongside your existing site, without needing to install database, daemon software, or additional dynamic web programming languages on your server. The static content generation could happen directly on your server if possible, or you could run the html generation tool locally and upload the output.
MoveableType has a tool like this. You still need somewhere to store the content of your blog, and for this MoveableType uses MySQL by default, so you'd still need to install a database somewhere, but the database could simply be one your local desktop.
MoveableType also has support via plugins or older versions that can retrieve data from a sqlite or other database. The advantage of sqlite is that it doesn't require installing daemons like MySQL does, you can just put a sqlite file on disk somewhere, give MoveableType the path to the file, and run the script to generate your static content.
There are likely other tools like MoveableType, and I have in the past generated blog-like web pages simply by writing small scripts to generate HTML. The main issue is just that you need somewhere for these scripts to fetch data from.
Another option might be to develop your blog using XSLT, ... with XSLT, you'd put the content of your pages in XML files, and then write a template in XSL that converts your XML to HTML.
If you google for 'static blog site generation' you might find other ideas/options, including Jekyll/github mentioned in one of the other responses.