13

I read about Page Reference, and the documentation states the usage of Page Reference:

  • To view or set query string parameters and values for a page

  • To navigate the user to a different page as the result of an action method

But when I go through some code examples it seems like developers code it like this:

  public PageReference retrievePlan(){

     //logic bla bla
     return null;
 }

Why does this code use PageReference as a return type while it only returns null? Can we just use public void retrievePlan instead of PageReference and returning null? Does doing this have any significance?

Improve this question
0

2 Answers 2

Reset to default
18

There seem to be two cases where developers use this pattern. The first case is the developer learns about action methods for the first time, and is led to believe they must use a PageReference return type for the function to work, since nearly all tutorials seem to do this. The second case is where a developer does this because they want to have the return type already set "just in case they need it later."

The truth is, this is a bad practice, and should be avoided. First, many developers come to rely on the method's return type to quickly figure out what the method's output will be. Seeing a return type of PageReference will trick developers into thinking a possible redirect could occur. This later gets codified into test methods, and so becomes reinforced.

It might not seem like a big deal when there are only five lines of code, but if a method contains two hundred lines of code, it becomes difficult to diagnose when something needs to be fixed. Or, a later developer might break something, assuming the return type is intentional, and changes the null to some PageReference.

There is no valid use for this anti-pattern, and you should never return a value when the result is always null. This also applies to other types of methods; never return a type if you only intend to return null.

Improve this answer
6
  • 1
    Can't emphasise your first point enough. I was taught that was how they worked when I first got started, took a couple of years before I realised you didn't need to return a PageReference. I
    – Matt Lacey ♦
    Commented Jan 14, 2015 at 7:22
  • Good answer. I never saw this addressed in any documentation, and example code that I've seen consistently uses PageReference for all actions.
    – Jeremy Nottingham
    Commented Apr 11, 2015 at 15:51
  • "The truth is, this is a bad practice, and should be avoided." This sentence is not really true. It's not a bad practice, it's just a convention that you may or may not use. Both void and PageReference = null need to be interpreted by someone who knows how viewstate in vfp behaves, so leaving it to void does not help in any way, but makes it harder to change logic when a bunch of "return;" statements are used to steer the logic within single method. Also treating action methods as every other method is wrong, as even with void it may change viewstate thus changing the whole page.
    – Jo_gurt
    Commented Aug 4, 2020 at 8:34
  • @Jo_gurt No, it is a bad practice, specifically YAGNI. In your first case, I would write a second method that calls the first to add a redirect. Problem solved. On the second point, code organization is important; all action methods should be next to each other and delimited by comments. The potential benefits on saving a refactor that may never come does not outweigh the cognitive complexity of simply using the correct return type. Like using an Integer[] to store a person's name or a String for their age.
    – sfdcfox ♦
    Commented Aug 4, 2020 at 14:40
  • @sfdcfox Wrapping a second method is a step in a wrong way since few seconds ago the old one was the exposed one. This cascades a bunch of changes not only in class, but also in UTs and page itself. I don't want to go into commenting stuff and oraganizing methods within classes, because this is a personal preference - again I don't agree with both of your comments there, but it is not a matter of good/bad practice. Bunch of "return;" statements for void methods may add to congnitive complexity. Returning PageReference for page actions is far from an array of integers to hold a single string.
    – Jo_gurt
    Commented Aug 5, 2020 at 15:12
4

If we assume an action method is a method invoked via some action= attribute on a VF page, then

  • When an action method returns null, it indicates to VF that the current page should be refreshed (such as when displaying errors or simply doing some ajax action)
  • When an action method returns a non null PageReference, then typically this indicates navigation to a different page (perhaps a new page in a multi-step wizard or a server-side redirection to a new page altogether)

Personally, I always declare my action methods as returning PageReference by convention but there are clearly examples where an action method won't navigate to a new page, and, as you've noted throughout SFSE, such methods are declared as void and work just fine

Note that the VF doc (Defining Action methods) does state the following in an example:

The save method ...takes the standard signature for an action method: it is public, returns a PageReference, and contains no arguments

...

Update - I see sfdcfox has weighed in here with a better answer

Improve this answer
3
  • 2
    It's more about verb use, I suppose. For example, a function named redirect() had best return a PageReference in at least one instance. Conversely, I wouldn't expect initializeExtension() to redirect, and I'd argue it should be a void return type. Contrast JavaScript's confirm() built-in versus Windows ShowDialog() built-in. Confirm is something you'd expect to get a result from, but ShowDialog also returns a result. Why? Because ShowDialog is actually a "confirm" function. Poor function naming is just as bad as non-obvious return values.
    – sfdcfox ♦
    Commented Jan 14, 2015 at 6:13
  • 1
    One use case for returning null is when an action should redirect, and is expected to according to it's name like you say, but then some validation reason prevents that redirect from occuring. Granted in this case you should split it up into two actions potentially but I think for some scenarios it's a legit reason. Doesn't justify doing returning null when you don't do any such checking of course :)
    – Matt Lacey ♦
    Commented Jan 14, 2015 at 7:27
  • I'll have to admit that when I saw the line in the VF doc 'The save method ...takes the standard signature for an action method: it is public, returns a PageReference, and contains no arguments' - I went 'all in' and declared all my action methods as return type PageReference even when the verb would not indicate navigation to a new page. @LaceySnr's example is something that occurs commonly for me - an action method, say, doClone() that does DML and redirects to a new page on success but if there's an error, returns null after creating an apexPages.Message.
    – cropredy
    Commented Jan 14, 2015 at 17:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .