Modules
Every GOX file declares a module.
The module defines the identity used to access public file members from other application modules.
Declaration of a module
The statement uses the keyword module and must appear at the beginning of the file.
module menu Each file declares a single module.
Public members
The functions, variables, constants and types declared with a public identifier belong to the module.
module menu
func Greeting(name string) string {
return "Hola, " + name
} After importing the file, the function is used by the name of your module:
message := menu.Greeting("George") Visibility
GOX retains Go's visibility rules.
The identifiers whose name begins with a capital letter are public:
func Greeting() string {
return "Hola"
} The identifiers whose name begins with a tiny letter remain private within the module:
func greeting() string {
return "Hola"
} No additional keywords are needed to define their visibility.
What a module can export
A module can expose any public member, including:
- Funciones.
- Variables.
- Constantes.
- Tipos.
- Componentes.
- Acciones.
- Canales.
The type returned by a function does not change the identifier's visibility rules.
Isolation between GOX inputs
Each GOX input is compiled and loaded as an independent plugin. GOX modules and Go packages that can be reached from that input are part of its compilation.
This isolation allows each Page, Action or WebSocket input to be compiled and updated independently. It does not represent a security sandbox, but does set a limit between the units compiled by GOX.
Import the same GOX module or Go package from two different inputs allows you to use your types, functions and methods, but it should not be considered a bridge to share status between these inputs.
For example, pages pages/index.gox and pages/login.gox can import the same package:
import "hello/billing" Both pages can use their functions correctly:
invoice, err := billing.CreateInvoice() However, they should not assume that a global variable declared within the billing is a shared and consistent storage between the two entries:
package billing
var attempts int
func RegisterAttempt() {
attempts++
} Although RegisterAttempt() can be run correctly from both pages, GOX does not guarantee that the state of attempts represents a single shared value among all compiled inputs.
Import shares the code's definition and behavior. It does not define a storage mechanism between plugins.
To keep information associated with a user, use the session storage:
if err := ctx.Session.Set("loginAttempts", attempts); err != nil {
return err
} To share information between the entries loaded by the current instance of gox-server, use gox.Storage:
gox.Storage.Set("loginAttempts", attempts) Choose the storage according to the range:
- Use
ctx.Sessionfor data associated with a session. - Use
gox.Storagefor shared data within the current instance. - It uses an external database or storage when the data must survive the reboot of the server or be shared between several instances.
Integration with Go
GOX modules complement the Go package system and provide identity to files .gox Its public members are consulted with the same notation and the same rules of visibility that are familiar to those who work with Go.
The Go packages keep their usual organization and resolution. The same file can import Go packages and GOX modules without turning one of these mechanisms into the other.
Best practices
- Declares a single module per file.
- It uses short and descriptive names.
- Keep the same name for the file and its module when appropriate.
- Group within the same module the members who share a responsibility.
- It keeps private identifiers that are not part of the public interface.
To learn more about The GOX languageSee your documentation. To learn more about ImportsSee your documentation. To learn more about Import aliasesSee your documentation. To learn more about Components, check your documentation.