How do I modify the auth smart package?
For example the dropdown box after registering show the buttons change password and sign out. I want to add an edit account button. How?
Thanks.
To add an edit button, look here:
https://github.com/meteor/meteor/tree/master/packages/accounts-ui-unstyled
Specifically, the login_buttons.html file.
update: There's a note at the top of the linked file:
NOTE: You shouldn't use these templates directly. Instead, use the
global {{loginButtons}} template.
Thus, you should find these files in your meteor installation (mine is in C:\Program Files (x86)\Meteor\packages\accounts-ui\login_buttons.html) and edit that file.
Note this will modify the accounts UI for all your meteor apps. If you do not want your changes to affect your other meteor apps, you will probably have to "fork" your own accounts-ui package.
There is discussion of making the accounts UI more customizable (like overridable templates), but it is not possible with the current version of Meteor. I suggest describing your use case to the meteor developers. The meteor developers openly welcome feedback:
Feedback, please! Some specific areas that we're curious about:
What sort of customization do you want to do to the loginButtons template?
What sort of account restrictions are you likely to use? Everyone must have a username? Everyone must have an email?
You can override the loginButtons, because currently the default helpers object is public for some reason:
Handlebars._default_helpers["loginButtons"] = function(options) {
return "hello this is test";
};
The original helper function looks like this:
Handlebars.registerHelper(
"loginButtons",
function (options) {
if (options.hash.align === "right")
return new Handlebars.SafeString(Template._loginButtons({align: "right"}));
else
return new Handlebars.SafeString(Template._loginButtons({align: "left"}));
});
Here you could replace the default _loginButtons template with your own.
However this could easily break with a future version of meteor as Handlebars._default_helpers is not really intended to be used in that way. But at least you don't have to work with a fork of meteor.
Also you have to make sure that you add your helper after accounts-ui-unstyled does. So if you are using this trick inside another package, be sure to declare accounts-ui-unstyled as a dependency.
Related
I need advice from the more experienced javascript(typescript) / nodejs developers. For a few months a I’m trying to find best practice for making extendable and modifiable node (npm) modules.
For better understanding: In most of PHP frameworks (like as Symfony, Laravel, Nette) we have DI container which can be used for changing or adding own implementation for services coming from packages. For example. I have a cart package which implements service for calculating cart price and apply taxes. When i need to change taxes calculation I can change implementation over DI container like as
services:
myTaxCalculator:
class: MyTaxCalculator
Package\Taxes\CalculatorInterface: ‘#myTaxCalculator’
and now when package work with Package\Taxes\CalculatorInterface use my own calculator instead of default implementation.
And I looking for something like this in javascript(typescript)/nodejs. If I build any package and in package I need function for calculate taxes use this const taxCalculator = require(‘...’) but now I can’t change implementation of this function.
Of course I can make package configurable. Add some mechanism for set a custom function for specific cases but I think that I need this logic for all classes / function which is used in application to never have to call require(‘something’).
The point is build basic and standard package with default logic which can be in concrete application modify to solve customer problems without writing a new package with 90% same code.
I know that exists some IoC/DI implementation for javascript(typescript) / nodejs like as InversifyJS but I’m not sure when is a best way for javascript(typescript) / nodejs applications.
Do you have any experiences with this? How do you solve these problems?
Thanks for any response!
I wouldn't say I'm an expert or "best practices guru", but I think three scenarios are pretty common. I won't dig into Inversify because you're already aware of it.
Take an object with config at the entry point class/function. Default to your implementation.
interface TaxCalculator { /* tax related stuff */ }
interface CalculateCartPriceArgs {
taxCalculator: TaxCalculator,
// probably lots of other stuff
}
export function calculateCartPrice({
taxCalculator = defaultTaxCalculator
}: CalculateCartPriceArgs) {
// implementation
}
Plugins / middleware.
Expose internals to allow the user to build his own version of your thing.
My Shopify app replaces the product pages 'Add To Cart' form / product form, with it's own form of sorts. It is Liquid logic that decides whether or not to render the entire <form> element.
This works great, but on some themes (like Jumpstart by Shopify), the product page bugs out completely, throwing me an error saying:
option_selection.js - can't access its "parentNode" property
Which I believe is the option_selection.js function where it is looking for the select box / variant ID somewhere on the page.
Of course, this variant ID / select box does not exist because it is not being rendered.
How can I replace the add to cart form while satisfying the option_selection.js functions?
Usually this wouldn't be a big deal, but Shopify's app review team will give me problems with this, and on the Jumpstart theme specifically, this error causes the product photos to not render; breaking the page completely.
Any ideas here? Much appreciated!
Axing the entire product form seems a bit extreme - there's no way to do what you need to do in a less invasive way?
Assuming not, you'll want to expand your install so that you can update any code in a theme that initializes the product form to take into account the possibility that you've defied the theme's simplistic assumptions.
For the option_selection.js compatibility, you'll be looking for where new Shopify.OptionSelectors is being invoked. If your code has set a variable through Javascript, that may be the easiest check to make. Example of an inline install that assumes your code creates a function named MyAppNamespace.isProdHidden:
Original:
new Shopify.OptionSelectors( ...
Updated:
!(window.MyAppNamespace && MyAppNamespace.isProdHidden({{ product.id | json }}) ) && new Shopify.OptionSelectors( ...
The added piece of code will evaluate to false if and only if your app has loaded properly and your isProdHidden function returns a truthy value. This scenario would prevent the new Shopify.OptionSelectors part from running, since we're using the && as a sort of short-circuit/emergency-stop operation.
If your app failed to load (or was uninstalled from the store without the liquid code being updated), or if MyAppNamespace.isProdHidden returns false, then the added block of code evaluates as true and the new Shopify.OptionSelectors happens as normal.
The above is equivalent to wrapping the entire new Shopify.OptionSelectors call in an if statement, with the install benefit that the party installing your app doesn't need to read the theme code to figure out where the OptionSelectors call ends. In most themes the OptionSelectors code is spread out over multiple lines and occasionally theme developers declare their onVariantChange function as an inline anonymous function - neither of which are big obstacles for experienced developers, but a huge complication for novices and store owners without this kind of expertise.
Making the status of your app available somehow through Javascript is probably the best thing for you to do as far as theme-install-compatibility goes. Some themes have their OptionSelectors call right in the product page, which can be affected by dynamic Liquid variables, but many have this code tucked away in a .js file in the assets folder instead. Still other themes don't use Shopify's OptionSelectors code at all and instead run their own thing, and thus your app could interfere in completely unexpected ways or places. Creating tools to make it easier to integrate your app into somebody else's code is therefore one of the best things you can do.
You'll also want to make sure that your code is able to handle multiple products, as many stores have quick-shops all through the site which can load arbitrary product forms. By making sure you have made the tools available, it's possible for you, your support team (if any) and theme devs can make the required updates to (almost!) any arbitrary theme.
Hope that helps!
I have developed a web app which is a QA forum using mean stack approach. Currently the project is working and I have implemented the basic requirements like login authentication using passportjs, then storing questions, answers, votes etc. in mongodb using mongoose.
Now I am required to add a state machine like workflow programmatically to the entire project where each module (eg.login module) will act as a state. And a flow for them must be defined.
I have looked into javascript workflow engines like workflow-4-node, bpmn.js, turbine.js. So my question is, how should I use these libraries without changing any code of my project, Is there any specific approach to do this, or am I required to change my entire code to implement the work flow.
Also in my project I am using ui.router(Routing module for angularjs) to switch between different pages and controllers (by using $stateProvider). So is this routing that I have implemented, and the state machine like workflow that I am required to do, same(different terminologies but same concept) or are they different?
NoFlo 0.8 provides a asCallback interface, allowing users to embed NoFlo graphs into existing JavaScript code.
So, if you have defined a NoFlo graph for a particular workflow, you can include it to your JavaScript app like this:
// Wrap a NoFlo graph
var myFunc = noflo.asCallback('my-project/MyGraph');
// Call the wrapped graph
myFunc({
inport: 'data'
anotherport: 'more data'
}, function (err, result) {
// Do something with the result
});
I just started using Ember for a real application, and already got myself into a bit of a bind.
I set up my environment.js file with the following:
modulePrefix: 'appname',
podModulePrefix: 'appname/pods'
However, this did not work and Ember CLI continues to generate files in the old/normal structure. I unfortunately did not even notice until I had a decent amount of work done... cause I was excited just to have an Ember app going! ;)
So the question I have is two-fold:
Why is podModulePrefix not working? I've read up on it, and it seems like it should be fine. I'm probably missing the point on why it's not working.
How can I migrate my existing file structure into the pod structure? Is it just manually doing so, or is there a tool out there that helps with things?
Thanks for any help!
I am going to answer
1- you should just stop Ember and start again and your code should be
podModulePrefix: 'app/pod', //just an example
then start creating a test component like
ember g component test-com --pod
the result would be this
installing component
create app/pod/components/test-com/component.js
create app/pod/components/test-com/template.hbs
installing component-test
create tests/integration/pod/components/test-com/component-test.js
2- no way, you must just simply create and copy and paste your code.
If you would like to use the pods structure as the default for your project, you can set usePods in your .ember-cli config file to true (setting was previously named usePodsByDefault). To generate or destroy a blueprint in the classic type structure while usePods is true, use the --classic flag.
With the usePods set to true.
// .ember-cli
{
"usePods": true
}
I am using Kickstrap 1.3.0 and want to add an App in my PHP-View with a method like <?php $this->enableKickstrapApp('myapp'); ?>. This method would put the app name into an apps array and the layout template could generate any code anywhere in the page to active the app.
But I don't know how to load the app. The docs say that I should add a page specific less file. But I don't want to autogenerate such an extra less file (I will do this it there is no better solution). Also an API method loadApp() is mentioned in the API docs. But there seems to be no loadApp in the source code. Also it is not documented how to get the API object (maybe this should be a global method--I couldn't find it). In an maybe outdated doc at GitHub I found the tip to write a pageApps array. But scanning the source code for "pageApps" also had no results.
Is there any way to activate an app dynamically (or in the global ks variable) without an extra less file?
That works:
var ks = {
apps: ['myapp']
}
Must be defined before loading kickstrap.js of course.